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THE  KNOWLEDGE- BAS ED  SOFTWARE  ASSISTANT 

Ovet  view 


Lt  Kevin  M.  Benner,  USAF  and  Douglas  A.  White 
Command  and  Control  Technology  Division 
Rome  Air  Development  Center 
Griffiss  AFB ,  NY  13441-5700 


In  1983  Rome  Air  Development  Center  (RADC)  published 
"Report  on  a  Knowledge-Bared  Software  Assistant"  [3]. 
This  document  brought  together  key  ideas  on  how 
artificial  intelligence  (AI)  could  be  used  in  the 
software  development  process.  Since  then  RADC  has 
embarked  on  the  first  of  three  contract  iterations  to 
develop  both  a  Knowledge* Based  Software  Assistant  (KBSA) 
and  the  enabling  supporting  technologies.  This  paper 
will  describe:  1)  History  leading  up  to  KBSA,  2)  What 
is  KBSA,  3)  Development  strategy  and  current  status  of 
KBSA,  and  4)  Concluding  remarks. 


HISTORY 


The  KBSA  research  program  is  a  natural  progression  of 
research  and  development  undertaken  by  RADC  in  its 
continuing  pursuit  of  a  solution  to  the  well  known 
"software  life  cycle  problem".  This  application  of  AI 
technology  to  the  problem  of  software  development  was  a 
predictable  outgrowth  of  RADC ' s  longstanding  commitment 
to  research  and  development  directed  at  enhancing 
productivity.  From  the  early  1970's  when  RADC  was 
championing  the  cause  of  "modern"  high  level  languages 
and  "structured"  implementation  methodologies,  a  less 
publicized  but  important  track  of  research  was  being 
addressed  on  a  smaller  scale  for  the  development  of 
greater  formalism  and  abstraction  for  the  objects  and 
activities  belonging  to  the  technology  of  software 
development.  The  publicity  given  to  the  AI  community  in 
the  late  1970 's  and  early  1980's  due  to  successes  in 
building  workable  expert  systems  and  the  announcement  of 
the  Fifth  Generation  Computer  Program  of  Japan,  resulted 
in  the  emphasis  of  AI  technology  within  RADC's  research 
program.  This  in  turn  led  to  the  examination  of  the 
possibility  of  applying  the  technology  that  worked  so 
well  in  areas  such  as  geological  analysis  and  locomotive 
maintenance  to  the  problems  of  software  development  and 
maintenance.  This  atmosphere,  when  coupled  with  the 
growing  compilation  of  results  from  earlier  research, 
encouraged  the  selection  of  software  development  as  an 
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application  to  drive  and  demonstrate  AI  technology 
research  developments.  The  particular  paradigm  rejected 
and  eventually  identified  as  the  FbCS  was  the  result  of 
careful  consideration  of  the  state  of  technology  as 
demonstrated  by  prior  work,  and  the  goals  and  p-ackicai 
requirements  of  a  system  to  support  software 
development . 

Throughout  the  ISXC's,  concurrent.  With  the  .■*.«  jot  RADC 
projects  in  1 anguage/compiler  systems  arui  programming 
methodologies,  efforts  were  undertaker,  which  explored 
formalisms  with  which  to  better  describe  the  objects  and 
algorithms  comprising  software.  Iz  was  re-'ognizecs  that 
there  were  many  flaws  with  the  existing  manner  in  which 
programs  were  created  and  the  languages  in  wnich  they 
were  expressed.  A  few  of  the  outstanding  problems  that 
were  addressed  during  this  time  includt._.;  programs 
could  be  syntactically  correct  without  providing  the 
desired  solution  or  being  logically  correct;  and,  even 
with  "better"  high  level  languages,  programs  were 
incomprehensible,  ever,  to  the  author  with  the  passing  of 
time.  Each  of  these  problems  and  the  research  efforts 
addressing  them  had  a  part  in  exposing  the  members  of 
the  Command  and  Control  Software  Technology  Division  to 
the  work  being  performed  in  the  world  of  Al ,  and  while 
simultaneously  providing  necessary  support  for  some  of 
the  important  Al  research  ideas  cl  the  came. 

The  problem  of  logical  correctness  of  programs  was 
attacked  in  many  ways.  However,  the  two  that  are 
important  to  the  KBSA  (even  though  not  receiving 
widespread  adoption  in  the  worlo  ot  software 
engineering.1  are  formal  proofs  of  correctness  and  formal 
specification  languages.  In  late  1974  ar  initial  effort 
was  undertaken  to  explore  the  apgl icaoiJ ity  of  formal 
verification  methods  to  existing  y .  og  ramming  languages. 
This  process  of  "verifying"  ?  prog; am’ s  correctness 
consists  of  establishing  by  mathematical  proof  that 
whenever  a  program  is  executed  with  specified  input  data 
and  execution  environment  the  execution  will  terminate 
and  upon  termination  the  values  of.  program  variables 
will  meet  output  specifications.  The  foundations  of 
formal  program  verification  are  identical  with  those  of 
a  significant  body  of  the  work  m  automatic  programming. 
As  might  be  expected,  many  of  the  same  individuals  are 
involved  in  both  areas  of  research.  The  need  for  formal 
specification  languages  was  emphasized  by  the  difficulty 
of  verification  of  programs  in  existing  computer 
languages.  In  1976,  research  was  initiated  to  develop  a 
"language"  that  could  be  used  to  provide  formal 
descriptions  cf  programs.  The  specification  languages 
resulting  from  this  research  were  found  to  be  unwieldy 
for  extensive  use  by  humans  and  as  is  the  case  with 
formal  program  verification  technology  are  not  known  to 
have  achieved  widespread  use.  However,  formal 
specifications  are  particularly  important  to  the  KBSA 
because  they  provide  the  formalism  needed  to  enable 
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reasoning  about  programs.  Additionally,  these 
particular  research  eirorrs  caused  RADC  to  become 
involved  in  a  progression  of  efforts  addressing 
automatic  programming  which  'o.tinue  today. 

The  need  for  a  more  natural  and  abstract  method  of 
expressing  a  problem  solution  to  a  computer  led  to  the 
exploration  cf  the  concept  of  a  Very  High  Level  Language 
(VHLL)  .  The  goal  of  this  researcr.  was  to  provide  a 
language  system  combining  one  capabilities  of 
conventional  languages  with  those  of  logic  programming 
systems  enabling  the  user  to  program  not  only 
computational  processes  in  tne  conventional  sense,  but 
also  "reasoning"  processes.  From  this  research  at 
Syracuse  has  emerged  an  evolving  family  of  languages 
which  exhibit  many  of  the  characteristics  that  will  be 
needed  in  the  Wide  Spectrum  Language  (WSL)  of  the  KBSA. 
This  research  was  facilitated  by  the  early  theoretical 
work  of  Robinson  [14]  which  has  provided  much  of  the 
foundation  for  logic  programming.  Through  this  work  at 
Syracuse  University,  wmch  began  in  the  mid  1970's,  RADC 
has  been  cognizant  of  the  potential  for  a  software 
development  paradigm  unlike  that  existing  for 
conventional  programming  languages. 

The  arrival  of  practical  diagnostic  systems  based  on  AI 
technology  in  the  late  1970 ‘s  led  to  a  project  to 
investigate  the  possibility  of  creating  a 
knowledge-based  system  that  would  diagnose  software 
systems  and  assist  in  their  maintenance.  The  conclusion 
of  this  investigation  was  that  this  type  of  diagnostic 
expert  system  would  be  impossible  for  software  because 
of  the  inadequacy  of  the  knowledge  about  software  in 
general  and  any  software  system  in  particular.  This 
initial  negative  result,  along  with  the  dim  prospect  for 
immediate  relief  from  automatic  programming  caused  a 
serious  consideration  of  the  alternatives.  The 
alternative  perceived  to  have  the  greatest  promise  was 
that  of  a  knowledge-based  system  that  did  not  provide 
total  automation  cf  the  software  synthesis  process,  but 
did  maintain  a  total  record  of  all  decisions  and 
activities  which  occurred  ir  the  creation  of  a  software 
system.  This  system  wouid  possess  the  expertise  to 
automatically  perform  many  of  the  tedious  tasks  of 
program  development,  out  would  be  guided  in  the 
application  cf  transformations  by  the  human  user. 
Communications  among  members  of  a  development 
organization  would  also  be  enhanced  by  the  monitoring 
and  reporting  capabilities  provided  by  the 
knowledge-based  system.  These  ire  the  concepts  that 
were  further  developed  and  described  in  the  1983  report 
considered  to  be  the  "defining  dociment"  cf  the  KBSA. 
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WHAT  IS  KBSA? 


The  KBSA  approach  is  a  departure  from  the  existing 
software  engineering  paradigm  in  that  it  attempts  to 
formalize  all  activities  as  well  as  products  ot  the 
software  life  cycle.  It  is  a  formalized 
computer-assisted  paradigm  for  the  development, 
evolution,  and  long-term  maintenance  ~>f  computer 
software.  KBSA  captures  the  history  of  system 
evolution.  It  provides  a  corporate  memory  cf;  how 
parts  interact,  what  assumptions  were  made  and  why,  the 
rationale  behind  choices,  how  requirements  are 
satisfied,  and  explanation  of  the  development  p-ocess. 
KBSA  accomplishes  this  through  a  collection  of 
integrated  dedicated  facets  and  an  underlying  common 
framework . 

KBSA  has  four  main  distinguishing  features.  First,  the 
specification  is  incremental,  executable,  and  formal. 
Incremental  means  that  the  specifier  may  gradually  add 
more  detail  to  the  specification  and  is  not  tcrced  to 
initially  describe  the  system  m  complete  detail. 
Executable  means  that  the  specification  is  "runnable" 
like  a  prototype.  This  allows  the  specifier  to  validate 
the  specification  against  user  intent  by  actually 
showing  him/her  the  "running"  specification.  Finally, 
formal  means  that  the  specification  is  expressed  in  a 
language  with  precise  semantics,  avoiding  the  ambiguity 
of  natural  language. 

Second,  the  implementation  is  formal,  that  is,  all 
decisions  made  during  the  implementation  are  captured 
and  justified.  Typically,  implementation  will  be  done 
via  correctness  preserving  transformations,  thus 
guaranteeing  by  default  a  verified  implementation. 

Third,  project  management  policies  will  be  formally 
stated  and  enforced  by  KBSA.  That  is,  project  policy 
will  define  the  relationship  between  various  software 
development  objects  (eg.  requirements,  specifications, 
code,  test  cases,  bug  reports,  etc.)  and  then  be 
enforced  by  KBSA  throughout  the  software  development 
process. 

Fourth,  and  finally,  maintenance  will  be  done  at  the 
requirements  and  specification  level,  rather  than  via 
patches  to  the  code.  That  is,  since  maintenance 
activities  are  normally  a  result  of  new  or  better 
defined  user  requirements,  it  makes  sense  to  reflect 
this  in  the  requirement/specification. 

In  order  to  build  a  KBSA,  the  authors  of  the  initial 
report  point  to  the  need  for  specific  supporting 
technologies.  These  supporting  technologies  fall  into 
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four  main  categories.  a  wide  spectrum.  language,  general 
inferential  systems,  domain  specific  inferential 
systems,  and  system  integration. 

A  wide  spectrum  language  (WSL)  is  a  single  language 
which  provides  the  user  with  the  aoility  to  capture  the 
formal  semantics  of  the  system  under  development 
regardless  of  the  level  of  detail  {or  the  step  in  the 
development  cycle,-  .  A  wide  spectrum  language  is  both  a 
language  and  an  environment.  It  must  provide  uniform 
expressibil ity ,  regardless  of  what  is  being  described 
(ie.  requirements,  specifications,  code,  test  cases, 
project  management  policy,  e  c'.  Not  only  must  a  WSL  be 
able  to  express  these  objects,  it  roust  do  so  in  a  way 
which  is  consistent  at  all  levels,  both  syntactically 
and  semantically. 

A  general  inferential  system  is  a  system  which  supports 
reasoning.  In  particular,  we  are  concerned  with  the 
overall  efficiency  of  this  reasoning,  how  to  capture 
such  things  as  logic  in  inference  rules  and  data 
structures,  the  cuaiity  of  explanation  generated  by  the 
system,  and  the  ability  to  apply  this  inferencing  power 
to  specific  domains. 

Domain  specific  inferential  systems  extend  general 
inferential  systems  to  include  aspects  unique  to 
software  development.  This  topic  focuses  on  the 
knowledge  representation  of  software  development  objects 
and  inference  rules  and,  in  particular,  how  they  can  be 
formally  represented  and  used  for  further  reasoning. 

System  integration  deals  with  the  inherent  competition 
between  facets  and  how  a  technology  base  can  be  put 
together  such  that  all  phases  in  the  software 
development  process  are  supported  sufficiently. 


DEVELOPMENT  STRATEGY  AND  CURRENT  STATUS  OF  KBSA 


when  the  KBSA  report  first  came  out,  it  was  clear  that 
the  supporting  technologies  were  not  adequately 
developed.  To  address  this  shortfall  a  KBSA  was  to  be 
developed  in  three  iterations.  The  first  iteration  was 
aimed  at  designing  the  individual  facets  and  seeing 
where  the  supporting  technologies  could  be  pulled  along. 
Additionally,  there  was  a  desire  for  an  advancement  of 
the  understanding  of  the  software  development  process, 
particularly  with.vi:  this  new  KBSA  development  paradigm. 
In  line  with  this  concept,  wotk  began  on  a  Framework 
(FW)  and  five  (5)  facets: 
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Project  Management  Assistant  (PMA) ,  Requirements 
Assistant  (RA) ,  Specification  Assistant  (SA), 
Performance  Assistant  (PA),  and  Development  Assistant 
(DA)  [DA  will  not  begin  until  FY  88].  Though  boundaries 
between  facets  may  appear  in  the  first  iteration,  they 
will  blur  in  the  second  iteration  and  disappear 
completely  in  the  third  iteration. 


First  Iteration 


The  results  of  this  have  been  twofold.  First,  each 
facet  has  pulled  at  the  supporting  technologies  such 
that  they  have  advanced  the  state  of  these  technologies. 
Universal  solutions  were  not  sought,  rather  solutions 
unique  for  each  facet  have  been  found.  Secondly,  each 
facet  developer  has  made  progress  in  formalizing  their 
particular  life  cycle  phase.  This  formalization  has 
focused  both  on  the  products  of  individual  phases  (eg. 
requirements,  specification,  and  code),  but  more 
importantly  on  the  process  of  how  these  products  came 
about.  In  this  section  the  basic  approach  and 
milestones  of  each  contractor  will  be  described. 
Included  in  this  description  will  be  the  formalization 
of  the  particular  life  cycle  phase  and  the  impact  on 
supporting  technologies. 

Work  on  the  definition  of  a  PMA  formalism  and 
construction  of  a  prototype  began  in  1984  [9].  Kestrel 
Institute  was  the  developer.  The  life  cycle  goals  of 
PMA  were  to  provide  knowledge-based  help  to  users  and 
managers  in  project  communication,  coordination,  and 
task  management. 

The  capabilities  of  PMA  fall  into  three  categories: 
project  definition,  project  monitoring,  and  user 
interface.  Project  definition  consists  of  structuring 
the  project  into  individual  tasks  and  then  scheduling 
and  assigning  these  tasks.  Once  the  project  has  been 
decomposed  into  manageable  tasks,  it  must  be  monitored. 
This  monitoring  is  in  the  form  of  cost  and  schedule 
constraints.  Also  included  in  monitoring  is  the 
enforcement  of  specific  management  policies 
(eg.DoD-Std-2167 ,  rapid  prototyping,  KBSA,  etc.).  In 
addition,  PMA  provides  a  good  user  interface  for  project 
monitoring  and  project  definition.  This  interaction  is 
in  the  form  of  direct  queries/updates,  Pert  Charts,  and 
Gantt  Charts. 


,v.-. 


The  above  capabilities  were  important,  but  would  be 
expected  of  any  project  management  tool.  What  sets  PMA 
apart  from  its  predecessors  is  the  expressibility  and 
flexibility  of  the  PMA  architecture.  Not  only  does  PMA 
handle  user  defined  tasks,  but  it  also  understands  their 
products  and  the  implicit  relationships  between  them 
(eg.  components,  tasks,  requirements,  specification. 


I  H 


« 

1M 


source  code,  test  case? 
Also  present  in 
p r og r  amm i ng - i n-  the- 1  a i  g  • 
derivations,  releases.. 


From  a  technical  perse: 
include:  tr.e  formal.'  .v 

objects  enumerated  ■.  co- 
time  calculus  fee  ?p:  _ 

between  software 
mechanism  for  directly  a 
policies. 

The  work  on  the  Key 
1985  by  Sanders  As  so. 
deal  with  the  .1  r :  e  •• 
process.  Sanders’  inte: 
enter  requirements  •  •.  v  . 
of  detail.  It  woul-  ■ 
do  the  necessary  rrollcri 
of  requirements  and  2'- 
requirements  as  c ; :  c  y  br-r 

RA  capabilities  incl 
viewpoints  'eg.  data 
transition,  and  fine.', 
and  smart  editing  tools 
and  the  ability  to  ?t.p 
requirements.  In  add  it  it 
knowledge  represents’: 
Constraint  Language  Er.vx  : 
identify  contradictions  a:. 

The  main  technical  :h: . 
informality  when  trying 
representation  of  tre 
supporting  incomplete  gra. 
interface  level,  but 
not  necessarily  complete, 
is  done  via  SOCLE  rd&* 
system  whim  supports  d 
tracing,  and  local  prop 
provides  application  spec  . 
which  is  used  to  .den', 
comparing  the  current  r 
requirements"  c.f  a  genei 
within  RA 1 s  knowledge  base 
used  to  generate  question;, 
sure  something  vital  has  n 
a  justification  f . r  the  b: 


em.ts,  and  milestones), 
e  objects  unique  to 
v. i s i ons ,  configurations , 


cm  advances  made  in  PMA 
he  software  development 
'•uvf.lopme.nt  of  a  powerful 
temporal  relationships 
objects  [  10 ]  ,  and  a 
g  and  enforcing  project 


.mi st ant  [2,  15]  began  in 
“it  main  task  of  RA  was  to 
.tire  of  the  requirements 
•••as  to  allow  the  user  to 
j.:ea  order  or  desired  level 
-opens ibility  of  RA  to:  1) 
to  allowuser  manipulation 
.infcain  consistency  among 


support  for  multiple 
>•  control  flow,  state 
'low  diagrams),  management 
.•cun  i  ze  the  requirements, 

:  free  form  annotations  to 

to  this,  RA 1 s  underlying 
Structured  Object  and 
cum  'SOCLE),  enables  RA  to 
cone  rate  explanations. 

nas  been  on  how  to  handle 
to  build  an  underlying 
-ut movents.  This  is  done  by 
■cm.  descriptions  at  the  user 
'taming  a  consistent,  though 
eternal  representation.  This 
provides  a  truth  maintenance 
.ov .it  reasoning,  dependency 
ration  of  constraints.  RA 
Lc  automatic  classification 
missing  requirements  by 
ruirements  against  "typical 
:  system  (already  represented 
This  comparison  is  then 
)f  the  specifier  to  either  be 
:  oeen  left  out  or  to  gather 
?>  rente. 


The  main  goal  of  the  Epc?o  if  icat  ion  Assistant  [1,  8]  is 
to  develop  a  formal  specif .cation  of  the  system  under 
development  and  then  vo  validate  it  against  user  intent. 
The  development  of  the  formal  specification  must  be 
supported  in  an  increment 3}  fashion,  modeling  the  way 
developers  typical lv  const met  specifications.  The 


validation  must  be  done  by  exposing  the  specification  to 
the  user  at  the  earliest  opportunity  ani  continued 
throughout  the  construction  process.  The  effort  to 
develop  a  KBSA  Specification  Assistant  begon  in  196b. 
This  work  is  being  done  at  the  University  cf  So  ithern 
California-  Information  Sciences  Institute  (ISI) . 

SA  capabilities  include:  an  incremental  specification 
language  which  is  executable  and  a  natural  language 
paraphraser  which  will  translate  a  given  specification 
into  English.  These  capabilities  have  been  built  on  top 
of  ISI’s  Wide  Spectrum  Language  AP5,  and  the  development 
environment  CLF.  SA  can  currently  handle  specifications 
of  a  couple  pages. 

The  main  technical  issues  concern:  1)  identification  of 
specification  statements  as  requirements  or  goals  and 
the  transformation  of  these  from  a  hign  level 
specification  into  a  low  level  specification  and  2) 
extracting  and  assembling  system  views  (ie.  reusing 
specifications  and  parts  of  specifications). 

The  distinction  that  ISI  makes  between  requirements  and 
goals  is  that  requirements  are  inviolable  constraints, 
while  goals  describe  general  behavior  which  may  have 
exceptional  cases  not  currently  covered  by  the  goal. 
With  this  distinction  in  mind  SA  provides  high  level 
editing  commands  to  further  transform  the  specification 
into  a  low  level  specification.  Requirements  are 
transformed  in  a  correctness  preserving  manner  to 
maintain  satisfaction  of  the  requirements.  Goals,  on 
the  other  hand,  may  be  "compromised"  in  order  to  handle 
exceptional  cases.  That  is,  after  a  transformation,  the 
meaning  of  a  goal  specification  may  change. 

Extracting  and  assembling  system  views  deals  with 
building  up  a  specification  from  smaller  specifications 
(ie.  reuse  of  other  previously  defined  specifications) 
as  opposed  to  the  top  down  refinement  presented  m  the 
previous  paragraph.  SA  can  combine  disjoint 
specifications,  but  tools  are  needed  to  aid  in  combining 
specifications  which  share  common  terms. 

The  Performance  Assistant  [4,  5,  6)  work  began  at 
Kestrel  Institute  in  1985  and  is  expected  to  run  until 
1990.  Long  term  goals  for  a  performance  facet  are  to 
guide  software  performance  decisions  at  many  levels  in 
the  software  development  cycle,  from  requirements 
specifications  in  very  high  level  programs  to  low  level 
code.  The  approach  is  to  combine  heuristic,  symbolic, 
and  statistical  approaches  which  will  provide 
capabilities  for:  symbolic  evaluation,  data  structure 
analysis  and  advice,  and  algorithm  design  analysis  and 
advice.  This  effort  is  focusing  on  data  structure 
selection,  performance  annotations  of  a  specification, 
analysis  and  propagation  of  performance  information,  and 
control  structure  performance  analysis. 
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support  programming-in-the-large  concepts  life 
configuration  control,  and  5)  provide  a  consistent  user 
interface. 

The  overall  results  of  the  first  iteration  wj.11  be  a 
KBSA  concept  demonstration  consisting  of  mostly  .loosely 
coupled  facets  with  the  exception  of  PMA  and  the 
framework  which  will  be  tightly  coupled.  E^ch  facet 
will  exist  on  separate  machines  and  comn.unic.ate  via  the 
framework.  The  framework  will  be  responsible  for 
maintaining  traceability  between  software  development 
objects  and  keeping  facets  updated.  Escabli  sr.inq  the 
initial  traceability  (eg.  the  relaticnsnip  between 
requirements  objects  and  specification  objects!  is  the 
responsibility  of  the  involved  facets. 

In  the  past,  each  facet  developer  has  had  their  own 
problem  domain  in  which  to  work.  In  general  these 
domains  have  been  small  or  toy-iike.  For  the  KBSA 
demonstration  the  problem  domain  will  be  the  air  traffic 
control  problem  (ATC) .  This  domain  has  the  advantage  of 
being  a  substantial  problem  with  a  variety  or  real  world 
issues  (ie.  real  time  requirements,  data  base 
management,  user  interaction,  interaction  with  the 
outside  world,  and  changing  or  not  well  erfined 
requirements)  .  The  intention  of  tn.e  demonstration  is 
not  to  solve  the  ATC  problem,  but  rather  tc  have  the  ATC 
requirements  be  a  driver  for  KBSA.  The  demonstration 
will  most  likely  focus  on  some  portion  of  the  overall 
ATC  problem. 


Second  And  Third  Iterations 


The  second  iteration  of  F.3SA  will  begin  at  the 
completion  of  the  framework  effort.  All  facets  in  the 
second  iteration  will  interact  witn  the  framework  and 
thus  each  other.  This  will  be  aor.e  by  either  building 
individual  facets  in  Honeywell's  frameworK.,  or  more 
likely,  individual  facet  developer.-  will  extend  their 
own  frameworks  (eg.  REFINE,  APS,  SOCLE,  etc)  to  adhere 
to  the  framework  specification.  Both  are  acceptable 
from  a  RADC  perspective.  Prospective  developers  must 
convince  an  RADC  that  either  1)  they  will  use  the 
Honeywell  framework  or  2)  that  their  framework  does  or 
will  soon  adhere  to  the  standard.  There  will  be  a 
mechanism  to  allow  for  some  deviations  from  the 
framework  specification.  This  is  important  since  at  the 
beginning  of  the  second  iteration  the  framework 
described  in  the  specification  may  not  be  sufficiently 
powerful  to  implement  all  facets  or  some  specific 
feature  of  the  framework  may  preclude  functionality 
necessary  for  a  particular  facet.  For  the  third 
iteration  there  will  be  no  exceptions. 


During  the  second  iteration,  work  will  continue  on 
individual  life  cycle  phases,  while  also  focusing  on  the 
interaction  between  facets  and  the  framework. 

For  the  framework  contract,  work  will  address  raising 
the  functional  level  of  the  framework.  The  goal  is  for 
individual  facets  to  be  concerned  only  with  activities 
unique  to  their  respective  facets,  while  the  framework 
will  be  responsible  for  all  generic  tasks  (eg. 
knowledge  representation,  knowledge  base  maintenance, 
communication  between  facets,  policy  enforcement,  and 
general  inferencing  capabilities). 


CONCLUSION 


In  conclusion,  there  has  been  progress  over  the  last 
four  years.  The  question  now  is,  how  close  are  we  to  a 
workable  KBSA?  The  answer  is  greatly  dependent  upon  the 
framework  specification  which  will  come  out  of  this 
first  iteration.  If  it  is  sufficiently  powerful,  we 
could  have  a  workable  KBSA  at  the  end  of  the  second 
iteration.  On  the  other  hand,  if  most  second  iteration 
contractors  have  to  make  generic  extensions  to  the 
framework,  we  can  not  expect  a  workable  KBSA  until  the 
third  iteration. 
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Abstract 

The  advent  of  personal  engineering  workstaiu  p?  has  brought  substantial  information  pro¬ 
cessing  power  to  the  individual  programmer.  Advanced  tools  and  environment  capabilities 
supporting  the  software  lifecycle  are  just  beginning  to  become  generally  available  However, 
many  of  these  tools  are  addressing  on!>  pan  of  the  software  development  problem  by  focusing 
on  rapid  construction  of  self-contained  programs  by  a  small  group  of  talented  engineers  Addi¬ 
tional  capabilities  are  required  to  support  the  development  of  large  programming  systems  where 
a  high  degree  of  coordination  and  communication  is  required  among  large  numbers  of  software 
engineers,  hardware  engineers,  and  managers.  A  major  player  in  realizing  these  capabilities  is 
the  framework  supporting  the  software  development  environment.  In  this  paper  we  discuss  our 
research  toward  a  Knowledge-Based  Software  Assistant  (KBSA)  framework.  We  propose  the 
developm*!!;  of  an  advanced  framework  containing  a  distributed  knowledge  base  that  can  sup¬ 
port  the  data  representation  needs  of  tools,  provide  environmental  support  for  the  formalization 
and  control  of  the  software  development  process,  and  offer  a  highly  interactive  and  consistent 
user  interface 

1  Introduction 

The  problem  however  has  several  positive  characteristics.  Since  the  early  1960s,  the  hazards  and  pitfalls 
of  large  software  development  efforts  have  been  we)]  documented  .Brooks72k  The  use  of  modular  designs, 
information  hiding,  ana  chief  programmer  teams  have  sought  to  address  this  issue  and  make  the  problem 
more  tractable  Tightly  coupled  toolsets,  high-level  programming  languages,  and  advanced  workstations  have 
sought  to  improve  programmer  productivity.  Yet  ever,  with  the  wide-spread  availability  of  these  technologies, 
the  ability  to  deliver  large  software  systems  that  are  maintainable,  extendable,  and  delivered  on  time  and 
within  budget  continues  to  be  an  elusive  goal 

;Brooks72  describes  these  problems  as  the  “software  tar  pit”  and  cites  four  kinds  of  scfiware  development 
categories  programs,  programming  products,  programming  systems,  and  programming  systems  products 
A  program  is  software  code  that  is  complete  in  itself,  ready  to  be  run  by  the  author  on  the  systt  m  on  which 
it  was  developed  It  is  the  stuff  commonly  produced  in  backyard  garages  by  highly  talented  individuals  and 
is  often  the  object  of  envy  by  many  software  managers  when  measuring  programm  er  productivity 

The  programming  product  has  all  the  characteristics  of  a  program,  but  it  can  be  run,  tested,  repaired,  and 
extended  by  anybody  For  a  program  to  become  a  programming  product,  it  must  be  written  in  a  generalized 
fashion,  and  thoroughly  tested  and  documented  so  that  anyone  may  use  it,  fix  it,  and  extend  it 

Similarly,  e  programming  syitem  is  derived  from  the  simple  program  by  integrating  several  programs  into 
a  collection  of  interacting  components  that  have  been  coordinated  in  their  common  function  and  created 
using  a  disciplined  format.  Often  programming  systems  must  be  constructed  to  be  used  in  an  environment 
other  than  the  one  with  which  they  where  developed-embedded  systems  for  instance  This  requires  greater 
interaction  and  coordination  with  other  software  and  hardware  components  where  the  target  environment 
has  stringent  limitations  on  memory,  performance,  and  basic  support  services. 

This  research  was  supported  by  RADC  contract  number  F30602-86-C-0074 
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of  the  organizational  ami  bookkeeping  tasks  or,  'he  machine  rather  than  the  programmer  To  solve  t  u  rren  t 
software  developntcr, ;  a..o  maintenance  problem^.  a  new*  lifecyl*  paradigm  for  the  develc:  me nt .  evolution 
and  maintenance  of  largt  sof'ware  projects  is  necessary  'o  produce  a  fundamental  cnaagr  in  the  way  software 
is  constructed  Maintenance  and  evolution  should  occur  by  modifying  the  specifications  and  then  rederiving 
the  implementation,  rathe'  than  attempting  to  dtrectly  modify  the  optimized  implementation  Since  the 
implementation  will  be  rederived  for  each  change  'bio  process  must  be  automated  to  increas*  reliability  and 
reduce  costs  biasing  he  new  paradigm  on  tiie  formalization  and  machine  capture  of  all  software  decisions 
allows  advanced  reasoning  mechanisms  to  assist  with  these  decisions  !Green83|. 

The  automated  rederivation  of  the  implementation  s'  T,  addresses  only  the  rapid  construction  of  programs  anc 
programming  products  However  the  volume  ■  <  mi  mv .  .1.  and  reasoning  mechanisms  useful  for  developing 
specific  at  ions  car.  also  be  used  to  address  tn-  coordination  and  communication  of  programming  systems 
Such  knowledge-based  techniques  provide  c  high  degree  of  tool  integration  and  support  for  large  projects 
The  specification  of  methods,  procedures,  and  >  on.  unications  by  large  programming  tear.c  that  occurs 
dr.r.r.g  the  soft w are  dev elopir.en;  process  result  in  a  se;  of  programmable  behaviors  called  a  program 

Osterweil?"  The  process  program  ensures  the  coordination  between  developers,  the  use  of  standards,  and 
the  integration  of  cost,  schedule,  and  technical  information  during  the  development  of  the  soft  war*  s.strn 
Operations  on  software  objects  and  necessary  communications  between  developers  can  be  au.cimst’calK 
initiated  rather  i-  ar.  re  j  .  ring  the  user  to  explicit 'y  remember  to  make  the  necessary  requests  This  ‘  ,rL  h.ne 
in  the  loop'  a!..-*s  the  matn.ne  to  encourage  and  enforce  the  policies  currently  but  only  intern. ;; o 
adhered  t.  m.  rsi)*:: 

3  Motivations  for  the  KBSA  Framework 

Software  engine-ring  frameworks  for  the  next  generation  of  programming  environments  mil  consul  of  a 
k  ■  w  l*dge  bas-  for  containing  project  data  inference  mechanisms  that  operate  on  the  kne  w  ledge  ba  -  and  a 
user  interface  to  assist  the  user  ir.  interacting  with  re  environment  To  supply  these  capabilities,  four  design 
oblective‘  motivated  the  development  of  the  KBSA  framework  1)  support  for  the  data  representation  needs 
of  lifecydr  tools  2)  support  f* >r  the  coordination  of  activities  that  occurs  during  the  sofiware  dr  •e'uprncn: 
process.  5!  suppo*.  for  multiple  levels  of  integration  of  tools,  and  4)  a  highly  interactive  and  consistent  user 
interface 

3-1  Representation  of  Programming  Knowledge 

Current  operating  systems  define  a  set  of  prescribed  file  attributes  used  by  the  applications  th*>  -uppo' 
file  access  data,  last  written  date  file  owner,  etc.  Only  the  file  contents  and  the  file  name  may  be  .ei.rran' 
changed  by  an  application  programmer  Access  to  the  file  object  is  limited  to  references  tc  the  system. -defined 
attributes  j'ually  with  a  cost  of  addit.onal  system  overhead  or  the  use  of  some  unenforced  fiie-nairirp  scheme 
to  categorize  cata.  The  framework  should  permit  applications  to  include  any  number  of  auribu.es  tc.  t:.e 
data  object  and  a'iov  the  data  object  to  be  accessed  associatively  by  any  one  or  more  of  the  ;.itribui t :• 
assigned  without  excessive  system  overhead 

The  availability  of  such  a  database  also  provides  an  efficient  mechanism  for  intenool  communication  and 
control  Balzer86  Characteristic  •;.(  certain  current  programming  environments  is  the  ability  to  jc.r  to¬ 
gether  two  toe  Is  such  that  as  information  is  produced  by  one  tool,  it  is  immediately  passed  to  the  next 
This  capability,  referred  to  as  'piping',  permit*  rapid  construction  of  new  tools  out  :f  ex. s' mg  toe.  pax's 
Kermghan81 

Akhoug.  highly  successful,  such  environments  suffer  from  significant  performance  limitation*  dt>e  to  twe 
major  structure..’  £aw3  the  passing  of  character  strings  through  pipes  is  inefficient  and  the  cf  daiaDow 
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and  for  characterizn  g  software  products  schedules,  and  users,  and  clausal  logic  for  describing  assertions  and 
for  reasoning  about  (he  ohjects. 

The  concept  of  programming  is  being  applied  to  itself  iOsterweil87,  As  a  program  is  «  description  ai. 
intended  behavior  that  i«.  to  be  executed  bj  a  computer,  so  should  a  process  program  describe  the  software 
development  process  that  is  to  be  executed  by  a  software  development  organisation  The  assumption  is  being 
made  that  if  the  process  can  be  formall)  described  then  it  can  be  automated  and  consistent!)  adhered  to 
B)  formalizing  the  methods  that  are  current!)  being  used  to  develop  software,  we  will  be  able  tu  correct 
deficiencies,  and  incrementally  enhance  the  wa>  software  is  constructed 


3.3  Integration  Strategies 

The  development  of  software  engineering  environments  that  make  use  of  current  tools  and  are  extensible  to 
new  tools  will  depend  heavily  on  the  integration  strategy  used  by  the  environment  Integration  refers  to 
the  ability  of  the  framework  to  control  and  coordinate  the  operations  performed  by  the  tools  and  to  ensure 
consistency  of  the  data  that  they  manipulate  Many  relationships  can  be  defined  among  tools  that  have 
not  been  designed  to  share  data  Relationships  exist  among  cost  data  managed  by  a  cost  tool,  scheduling 
information  managed  by  a  scheduling  tool,  and  the  activities  of  design,  code,  and  test  being  performed  on 
the  software  products  b>  the  sof'ware  tools 

Characters •  lc  :r  most  knowledge-based  tools  that  will  be  integrated  into  our  framework  is  the  tendenc) 
to  be  embejjcd  »n  their  own  local  frameworks  The  local  frameworks  support  individual  forms  of  data 
representation  ard  inference  mechanisms  thus  satisfying  the  specific  needs  of  the  tool.  As  a  result,  our 
framework  is  constructed  as  a  “framework  for  frameworks"  providing  programming  system  support  to  local 
too!  frameworks 

The  four  KBSA  facet  efforts  that  have  been  completed  or  are  in  progress  are  supported  by  three  different 
local  frameworks  Socle  |Harris86  ,  which  supports  the  Requirements  Assistant,  is  a  frames-based  system 
that  has  been  extended  with  mathematical  constraints  The  mathematical  constraints  provid"  a  “triggering* 
capability  to  continual!)  reestablish  consistency  of  the  knowledge  base,  giving  an  electronic  spreadshee'  effect 
Whenever  one  of  the  inputs  is  changed,  the  computation  is  reevaluated  so  that  the  effects  of  the  change  are 
full)  propagated 

The  Specification  Assistant  is  based  on  the  Common  Lisp  Framework  (CLF)  iCLF85;.  CLF  provides  pro 
gramming  environment  primitives  (modules  and  workspaces)  used  to  represent  programme?  knowledge 
The  system  is  based  on  the  very  high  level  language  AP5,  an  extension  of  Lisp,  that  prov  ides  a  relational 
representation  of  the  knowledge  that  can  be  accessed  and  described  using  first-order  logic  formulas 

Final!)  Re  ftnc.'™  Refine86  is  used  to  support  both  the  Project  Management  Assistant  and  the  Performance 
Assistant.  Refine  is  the  most  advanced  framework  from  a  production  quality  perspective  and  is  an  integral -d 
language-programming  system  along  the  lines  of  Smalltalk  and  CommonLisp.  The  environment  is  designed 
to  be  a  manipulator  of  the  language  in  which  it  is  constructed.  The  language  merges  a  functional  language 
containing  Lisp-like  characteristics,  an  object-oriented  capability,  and  a  first-order  logic  capability  The 
system  is  focused  on  rapid  construction  of  Refine  programs  by  the  single  user 

From  this  list  of  frameworks,  we  believe  several  common  characteristics  can  be  identified  Each  system 
supports  an  object-oriented  or  frames-based  view  of  programming  knowledge  that  has  been  augmented  w  ith 
inference  mechanisms  for  making  logical  assertions  about  the  knowledge.  By  removing  overlapping  anti 
conflicting  capabilities,  a  set  of  “common  denominator"  capabilities  that  will  be  initially  supported  b)  a 
common  framework  can  be  defined.  This  list  will  provide  similar  capabilities  to  what  eacn  facei  expects 
from  its  own  framework.  As  new  tools  and  capabilities  are  defined,  the  our  framework  must  be  sole  to  be 
modified  and  extended  to  meet  these  new  requirements 
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3.4  Consistent  User  Interface 


In  ary  'r-'er  w  ith  which  a  user  must  interact  to  effectively  accomi  nsh  useful  work 
p>)ays  «  cru’it.  -ole  Herat)**  of  the  rang*  and  amount  of  information  t'aiiabic, 
user  sophistication  a  powerful  end  flexible  user  interface  well  be  critical  Currrr-.i-- 
appb*d  to  const'  rf.r.p  a  working  user  interface  This  “fctim  describe*  uhr  prir.ci:.* '. 


The  knowledge  base  will  contain  project  management  informaucn  such  as  sr.htdfKu  1'-.  ,  v  source-, 

resource  allocation  costing  data,  project  structure,  and  policy  It  will  contain  technic* ;  '  :  it'  r.  «vch  ... 

requirements  specifications,  code,  test  data,  and  test  results.  Users  will  include  tec  t'v  i.  -  a  •  ■  •  s  t-  ..hr. -telly 
naive  management  and  everyone  in  between.  A  useful  software  development  environm?..-  ;  v-  -  -cr  :-- 
mans  ktnd«  of  user  requests  for  a  variety  of  different  kinds  cf  information  and  assist  c. 

We  have  identified  several  concepts  that  are  fundamental  to  user  interfaces.  First,  Lie  of  irter.icvicn 

must  be  consistent  Th»  same  mechanism  should  be  used  to  perform  the  same  opera’.  on  r,  d’ff-Tt 
context  For  example,  it  is  undesireable  for  a  requirements  editor  to  be  invoked  via  t  re.  ''if1  ,  ’;r' 

while  the  specihoat ion  editor  is  invoked  via  mouse  selection. 

Help  and  query  facilities  that  provide  accurate  up-to-date  information  must  be  access’- ole  using  a  consistent 
interface  A  help  facility  should  be  available  to  the  user  at  an)'  time  and  withtr  a.iy  context  uv  r.q  >.  common 
mechanism  for  requesting  help  Exit  from  the  help  processor  should  return  ir  lire;-  to  the  original  n-ite. 

Second  the  interface  should  be  friendly  [Meads65j.  That  is,  it  should  pro' id*  vaobt'us  ' e  access  to  the 
system  which  puts  the  user  at  ease.  A  friendly  interface  .s  cooperative,  forgiving,  and  conducive  A  coop¬ 
erative  interface  actively  assists  users  by  keeping  them  aware  of  basic  capabilities,  etK  u'rtiging  exploration 
of  additional  capabilities  and  keeping  the  user  informed  on  what  the  system  is  dc.i  j  tn  i  ’-hat  progress 
is  being  made  A  cooperative  interface  will  allow  the  user  tc  suspend  a  tesk  and  qur.h'.v  rotuir  tc  it  t.t 
some  lai»*  time  without  loosing  context  or  information.  A  forgiving  imerlec"  is  desl  m-d  .:  expect  mistakes 
by  automat  re.  by  correcting  simple  errors  and  allowing  the  user  to  east1)  reever  fr<.  r.  '.  ...;’der»  Finally  & 
conducive  interface  is  reiiable.  predictable,  and  encourages  tn»  user  to  expire  r  ntw  c bilities  without  f»ai 
of  d'-strcyir.g  vita:  information 

Third,  the  in’e-face  shv-u>d  provide  access  to  intelligent  tutoring  mid  query  fecilit'es  b"'rdh,vi:;<urS2  .  Stud¬ 
ies  have  shown  that  such  on-line  assistance  can  substantially  affect  i  system’s  effectiveness.  useH’ity.  an j 
leart.abilitx  t  >ers  require  easv  access  to  information  „{iat  describe  features  and  functi .’u.&iiiy  of  tool'  well 
a*  to  data  ir  the  knowledge  base  su'h  as  available  resources,  schedules  anc  task  assignments 

Finally  sin-<-  users  will  nave  diverse  backgrounds  and  varying  degrees  of  technical  kncwled'rc  the  interface 
should  ha.es  -me  merr.amsm  for  user  modeling  WahlsterPft  This  includes  determining  and  reca-iir.j,’  beliefs 
goals,  plans,  and  knowledge  characteristics  of  the  use-  ;n  an  attempt'  to  tailor  the  system's  interact  ion  In 
doing  so.  the  system  can  more  appropriately  determine  whs:  kinds  of  mm. -rr  at  ion  to  supply  -no  e. lively 
assist  the  user  in  achieving  goals 

Many  approaches  can  be  taken  to  satisfy  these  requ'rem fo-  a  good  user  inerftc  T- *c  suggest., 
sev  en  facors  tc  consider  ir  determining  how  to  pre >  ,de  required  '»>  f.opatitv 

1  C ..si  of  th<  interface  Different  k ,nds  of  interfaces  (me. > u  command-l:.'  gr.p.io..  u- ,  ■  1- . 

ei  -  ;  require  differing  amounts  of  effort  m  impleire n8  -on  anc’  mi.rucra.i  •  -m 

talar  ed  agains:  the  inquired  functionality 

2  Fas'  of  .earning  Some  interfaces  (menu,  natural  language)  are  easier  to  Tr< 

J.urrfa  r  complexify  must  be  geared  toward  the  user  community 

3  C  -nciseress  bom*  interfaces  are  more  concise  %r  d  require  less  interaction  to  ,i 

The  conciseness  verbosity  of  the  interface  must  correlate  with  the  tasks  ir.  t«:  . 

4  N-ed  for  precision  Some  interfaces  are  less  precise  (natural  language)  than  ...  ■ 

the  interface  must  match  the  precision  required  by  the  task 

f>  Nerd  f.-r  pmtimes  In  some  cases,  pictures  communicitf  information  n  un, 
interface  should  be  capable  of  displaying  pictures  whenever  appropriate 

f  ?etre.r.ii-  complexity  Th»  required  complexity  of  the  interface  is  dmeetiy  -  •.»..• 

t  i»xi:y  of  the  ’ask  being  performed  The  interfare  must  balance  ns  own  -  ■ 

1  i-.e  ;  a1  k‘  r  will  t.e  use,!  m 


•  i 
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7  Promising  more  than  can  be  delivered.  In  most  cases,  if  a  system  has  a  complex  interface,  users 
will  expect  complex  behavior  from  the  underlying  system.  The  interface  must  not  mislead  users  by 
shrouding  a  simple  system  in  a  complex  interface. 

4  Architecture  Overview 

Figure  2  describes  the  overall  architecture  of  our  framework  Each  tool  and  its  knowledge  base  are  used  by 
the  programmer  on  separate  Common  Lisp  platforms  called  “Lisp  worlds."  A  Lisp  world  is  a  Lisp  virtual 
address  space  where  Common  Lisp  applications  may  execute  but  may  not  directly  interact  with  other  Lisp 
worlds.  The  KBSA  framework  is  responsible  for  all  communication  between  the  Lisp  worlds. 

When  a  tool  is  invoked,  it  is  loaded  into  a  Lisp  world  and  run.  Tools  having  their  own  framework  will  be 
loaded  with  an  initial  context  prior  to  execution.  Conversely,  when  the  operation  has  finished,  the  local  Lisp 
context  is  restored  to  the  KBSA  knowledge  base  to  enable  sharing  the  information.  The  tool  will  optionally 
remain  loaded  in  the  Lisp  world  to  facilitate  subsequent  executions. 

These  capabilities  are  supported  by  two  KBSA  framework  components:  knowledge  base  and  client  handler 
Each  of  these  components  are  described  further  below. 

4.1  Knowledge  Base 

The  knowledge  base  manages  the  “corporate  memory*  for  the  programming  environment  including  tools, 
project  data,  and  project  policy.  It  is  constructed  on  a  single  Lisp  world.  All  objects  managed  by  the 
knowledge  base  are  defined  and  manipulated  using  four  types  of  constructs:  object  schema,  methods,  rules, 
and  demons  Object  instances  defined  by  the  schema  may  be  distributed  across  multiple  workstations,  be 
associatively  accessed  using  any  combination  of  their  attributes,  conform  to  an  access  control  policy  and 
contain  a  derivation  history  of  all  changes  made  to  the  object.  The  knowledge  base  will  enforce  project  policies 
and  data  integrity  relationship  on  all  object  instances  using  the  rules  and  object  constraints  described  to  it 

The  four  construct  types  provide  the  characteristics  of  object-oriented  programming  together  with  a  logic 
system  for  declaratively  describing  relationships  between  objects  and  inferring  results  Each  of  the  constructs 
are  defined  further. 

Object  Schema  and  Methods  Objects  and  methods  in  the  knowledge  base  support  abstractions 
characteristic  of  object-oriented  programming  environments  |Goldberg84'  that  have  become  popular  This 
concept  ha;  been  extended  by  adding  additional  characteristic  of  logical  assertions 

Each  slot  in  an  object  schema  can  be  annotated  with  logical  predicates,  called  slot  assertions  which  formally 
describe  either  the  contents  of  the  slot,  or  a  function  for  computing  its  value.  These  predicates  and  functions 
are  used  to  establish  policies  about  object  classes  and  ensure  integrity  of  the  data. 

Object  schema  define  an  object  class  containing  a  name,  optional  supertypes,  and  a  list  of  slots  Methods 
define  the  messages  accepted  by  the  object  class  and  the  operations  that  manipulate  its  instances. 

Demons  A  demon  associates  an  object  method  with  a  predicate  condition  The  method  is  invoked 
whenever  the  predicate  is  satisfied  The  bound  variables  to  the  logic  query  are  used  as  parameters  to  the 
method 

When  a  demon  is  triggered,  the  method  is  executed  in  the  Lisp  world  whose  operation  on  the  knowledge  base 
resulted  in  the  demon  predicate  being  satisfied  Demons  are  a  primary  mechanism  used  describe  program 
management  policy 
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Rules  Rules  describe  logical  predicates  used  to  infer  relationships  in  the  knowledge  base.  They  will  Se 
used  in  both  slot  assertions  and  demons. 


4.2  Client  Handler 

The  Client  Handler  manages  the  context  of  a  single  user  Lisp  world.  It  receives  messages  sent  from  the 
knowledge  base  to  load  data  objects  into  the  Lisp  world  and  to  execute  object  methods.  It  is  also  responsible 
for  providing  a  transparent  interface  between  tools  and  the  central  knowledge  base.  The  client  handler  is 
the  network  manager  for  a  single  node  and  ensures  that  the  data  on  the  local  node  and  the  knowledge  base 
remain  consistent. 


4.3  Implementation  Details 


A  prototype  with  some  of  the  characteristics  of  the  system  described  has  been  constructed  to  provide  a 
testbed  for  experimenting  with  framework  concepts  It  is  hosted  on  a  network  of  Symbolics  workstations 
and  makes  use  of  the  Symbolics  networking  protocols.  The  following  section  presents  the  details  of  the 
implementation. 


Communication  and 
Framework  Interface 


Common 

Loops 


LogLisp 


Common  Lisp 


Figure  3:  Framework  Internal  Organization  87-CRV-1082 

The  objcct-orierted  and  predicate  logic  capability  is  provided  by  unifying  the  LogLisp  !Carciofini86l  language 
with  C  ommonLoops  |Bobrow85l  as  shown  in  figure  3.  CommonLoops  is  a  set  of  object-oriented  extensions 
to  Common  Lisp.  LogLisp  is  a  language  which  introduces  a  Horn  clause  theorem  prove?  into  Lisp  As  object 
classes  and  instances  are  created  predicates  axe  asserted  into  LogLisp  to  map  the  unification  semantics  onto 
the  object  slots  and  values. 

Both  slot  assertions  and  demon  objects  specify  LogLisp  queries  used  to  determine  slot  values  and  invoke 
methods  respectively  Each  modification  or  creation  of  an  object  results  in  the  list  of  predicates  being 
evaluated  The  associated  method  is  invoked  or  slot  value  assigned  for  those  predicates  returning  values 
Index  tables  are  constructed  to  assist  the  knowledge  base  minimising  the  number  of  predicates  evaluated  for 
each  knowledge  base  operation. 

LogLisp  also  provides  a  powerful  associative  access  mechanism  to  any  object  in  the  knowledge  base  by  simply 
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formulating  a  query  containing  the  attributes  of  the  desired  object.  This  enu;- 
constructing  complex  access  structures  to  the  objects  of  interest  and  instead  mamy  • 
their  attributes 


5  Conclusion 

We  have  described  the  requirements  and  motivations  of  a  common  KBSA  frr.rr  ■  ■  o-  ,.. 

services  not  available  in  the  tool  frameworks  An  initial  architecture  for  such  a  sys.  r,  ■< ..  I  .  ,  t 

well  as  its  implementation.  The  construction  of  advanced  software  engineering  frtt,;'  „»•.  :s  tv...  .  c.v 

ih  from  mans  other  developing  technologies  of  large  databases,  distributed  corr.r-i,.- -  ;  ceras 
languages  and  natural  language  understanding.  In  our  investigation  of  frame v«-  h*.vv  t.. 
examine  a  broad  spectrum  of  relevant  topics  without  failing  into  any  of  the  tc-cr.  ‘  yd  ; 

Thus,  several  issues  remain  to  be  adequately  examined.  Many  of  these  are  -v-d  fc:  -  t-  ‘ 
and  include  locking  and  serialising  knowledge  base  transactions,  improving  system,  ;  ,•  n  /  C' 
our  integration  approaches  with  actual  knowledge-based  tools.  We  ascribe  tr  <r'\. c 
develop  solutions  to  these  issues  and  therefore  will  continue  to  expand  the  prctw./’rc 

The  real  success  of  the  approach  however,  will  be  determined  by  the  ability  to  v  .  y  ; .  .» 
minimal  set  of  software  development  tools  into  the  framework  and  begir.  vrir.c  ■  e  '  ; 

itself  To  achieve  this  goal,  we  have  begun  to  integrate  an  internally  available',  v  :  item  shell  arc  ' ;  r.  c  r 
Lisp  based  tools  into  the  framework.  This  has  been  particularity  useful  in  cort  r.  ....  ruil  ov.  1  _r-  bail, 
to  reality  where  performance  and  manipulation  of  large  amounts  of  information  s 
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AN  OVERVIEW  OF  THE 
KNOWLEDGE-BASED 
REQUIREMENTS  ASSISTANT 
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The  Knowledge-Based  Requirements  Assistant  (KBRA),  is  an  intelligent 
assistant  computer  program  designed  to  actively  assist  engineers  m  the 
requirements  acquisition7  and  analysis  for  complex  software  system.  As  a 
component  of  the  the  Knowledge-Based  Software  Assistant  IKBSA)  effort, 
KBRA  addresses  the  KBSA  requirements  facet  goals  as  outlined  in  "Report 
on  a  Knowledge-based  Software  Assistant"  [Green,  Luckham,  Balzer, 
Cheatham,  and  Rich],  These  goals  include  forma: ization,  knowledge-based 
editing  and  management  of  requirements,  requirements  review,  and 
requirements  testing. 

We  have  found  it  useful  to  liken  our  KBRA  to  a  junior  assistant  charged 
with  the  management  of  a  requirements  engineer’s  notebook.  This 
management  entails  carefully  recording  information  along  with  the 
dependency  relationships  among  requirements  statements,  generating 
requirements  statements  from  alternative  points  of  view,  critiquing 
requirements  statements,  and  noting  inconsistencies.  Creating  this  behavior 
in  an  assistant  program  has  required  careful  attention  to  the  division  of  labor 
between  the  assistant  and  the  requirements  engineer.  The  assistant  knows 
the  vocabulary  of  requirements  work  and  will,  at  appropriate  times,  tak»  the 
initiative  to  check  for  consistency  and  propagate  information.  The  engineer  is 
always  in  charge  and  uses  the  assistant’s  input  to  help  make  the  key 
decisions 

This  paper  indicates  the  KBRA  problem  definition,  describes  the  KBRA 
system,  very  briefly  summarizes  the  knowledge  representation  approach,  and 
finally  points  out  the  relationship  of  KBRA  to  related  research. 

1  Acquisition  of  requirements,  as  used  here,  means  the  declaration  of  ideas  and  their 
placement  within  some  model  or  models  of  the  system  to  be  built. 

This  work  has  beea  funded  by  the  Rome  Air  Development  Center  at  Griffis*  Air  Force 
Base  in  New  York  under  Contract  No  F30602-85-C-0267 


DECISIONS  FOR  KBRA  PROBLEM  DEFINITION 


KBRA  is  a  first  step  on  the  road  toward  machine-mediation  of  requirements 
work.  There  have  been  many  important  problems  to  investigate  and  we  have 
had  to  decide  how  to  best  allocate  resources  in  addressing  these  problems. 
Three  major  decisions  stand  out  as  influential  on  the  character  of  KBRA. 
These  are  the  use  of  realistic  DoD  examples,  the  choice  of  an  integrated 
facilities  approach,  and  the  development  of  a  workstation  approach  to 
acquisition  of  requirements. 

Realistic  Examples 

A  requirements  facet  must  address  programming  in-the-large.  DoD  projects 
are  often  large  and  overwhelming-}-  complex.  It  is  crucial  that  engineers  can 
"get  a  handle  on  the  problem’.  In  order  ».;>  ensure  that  we  addressed  the 
really  significant  problems  associated  with  complexity  (and  that  our  results 
can  hence  be  rapidly  assimilated  into  the  DoD  community),  we  have  made  a 
strong  commitment  to  using  realistic  DoD  examples.  We  began  the  project  by 
developing  a  protocol,  in  the  form  of  a  working  notebook  of  requirements 
work  on  an  .Air  Traffic  Control  System.  This  protocol  includes  requirements 
for  item::  such  as  system  administrative  functions,  tracking  capabilities  and 
flight  r-h-n  maintenance.  If  anything,  the  study  reinforced  our  concern  that 
efforts  to  get  a  handle  on  requirements  problems  are  exploratory  in  nature 
with  system  description  evolving  through  incremental  changes  over  many 
iterations.  The  Air  Traffic  Control  domain  was  chosen  as  representative  of 
the  complex  but  conventional  software  systems  which  are  targeted  for 
development  using  KBRA. 

We  have  used  this  protocol  extensively  in  directing  our  own  work.  In 
addition,  it  has  been  adopted  by  the  Knowledge-Based  Software  Assistant 
Community  as  its  common  example  problem. 

Integrated  Facilities 

We  selected  an  integrated  facilities  approach  over  a  prescriptive  approach. 
The  facilities  that  have  been  developed  include  1)  capture  of  informal 
requirements  through  an  intelligent  notepad,  2)  capture  of  dependency 
relationships  using  familiar  calculator  and  spreadsheet  formats  tailored  to  the 
relationships  between  requirements,  3)  management  of  complexity  through 
presentation  of  familiar  system  description  concepts  (data-flow,  functional 
decomposition,  state  transition!,  spread  sheets,  and  explanations  of 
requirements  entities,  4)  knowledge-based  editing  of  these  presentations,  5) 
critiquing  of  requirements  work,  and  6!  completion  of  partial  descriptions. 
Examples  of  some  of  these  will  be  presented  in  the  descriptions  and  figures 
below. 

These  facilities  are  integrated  through  KBRA  mediation  of  the  requirements 
specification  process  and  through  integrated  reasoning  processes.  Throughout 
this  process,  KBRA  checks  for  consistency,  mamtams  dependency'  links,  and 
propagates  decisions  by  U3ir.g  an  integrated  collection  of  inference  processes 
KBRA  does  not  enforce  a  particular  methodology  In  fact,  KBRA  does  not 
contain  a  process  model  for  requirements.  We  felt  tiiat  an  uivestigation  of  a 
requirements  process  model  was  not  appropriate  at  this  stage  due  to  the 
present  lack  of  formalization  at  the  requirements  level. 

Workstation  Acquisition  Medium 


KBRA  provides  f.  "workstation*  kno -Hedge  acquisition  medium  KBRA  allow* 
an  engineer  to  enter  information  in  a  "natural"  <i.e  close  to  the  application) 
engineering  language  of  graphics  and  informal  note-.  The  workstation  is 
intended  to  be  used  from  the  first,  day  of  a  project  when  engineers  are 
merely  sketching  cut  solutions  informally  end  relating  associated  thought*. 

The  acquisition  medium  approach  reflects  our  recognition  that  requirement* 
work,  much  more  so  than  other  software  engineering  practice,  is  about 
acquisition  The  essence  cf  what  requirements  engineers  dc  is  acquire  and 
apply  knowledge  about  specific  domains.  By  providing  a  workstation  medium, 
we  have  been  able  to  build  KBRA  so  that  1)  it  is  accessab'e  by  end-user*,  2) 
the  results  of  machine- mediation  are  immediately  evident  to  these  end-user*, 
and  3>  feedback  from  erd-users  is  Incorporated  tc  improve  the  system. 
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As  an  illustration  of  the  medium,  the  figure  is  an  example  of  the 
"Intelligent  Notepad"  acquisition  vehicle.  The  "nates"  Bhcwn  are  entered  by  a 
user  who  wished  to  describe  a  next  generation  air  traTic  control  system. 

When  working  with  the  notepad,  an  engineer  can  freely  enter  associated 
information  taking  advantage  of  extensive  associative  retrieval  capabilities  that 
are  part  of  the  mte’ligent  assistance  prov/hd  by  KBRA  Associative  retrieval 
refers  to  KF.RAc  capability  to  access  information  which  impinges  in  some  way 
on  a  requirements  entity.  Examples  of  this  would  include  finding  a  function 
which  produces  a  data  item,  finding  text  strings  that  contain  a  word,  or 
finding  an  activity  that  plays  a  particular  role  :n  an  evolving  system 
description 

This  focus  o.i  acquisition  ar.d  the  associated  informality  of  requirements 
specification  arc  areas  m  wnich  KBRA  is  significantly  different  from  more 
conventional  app-tvrbev  to  supporting  requirements  work. 


THE  KBRA  SYSTEM 

The  above  decisions  and  the  Knowledge-Based  Software  Assistant  metaphor 
have  together  guided  our  work  on  KBRA.  In  this  section,  we  will  briefly  point 
out  the  mean  features  cf  the  current  KBRA  prototype. 


Incremental  Formalization 

KBRA  supports  incremental  formalization  of  requirements.  In  other  words, 
information  that  is  informal  (e.g.  keywords,  unparsed  text  strings)  is  stored 
along  with  formal  requirements  statements  (decomposition,  data  flow,  event 
definition,  and  performance  characterization).  Thus,  KBRA  never  degrades  to 
a  text  editor,  but  rather  provides  for  the  editing  of  all  text  at  the  logical  level 
within  the  context  of  the  evolving  system  description.  This  notion  has  been 
referred  to  in  (Sterpel  as  "structured  text". 

As  work  proceeds,  KBRA  analysis  capabilities  maintain  dependency  links, 
propagate  information,  and  check  for  consistency  as  informal  is  replaced  with 
formal.  We  will  briefly  describe  each  of  these  analysis  capabilities.  Dependency 
links  are  realized  as  a  form  of  truth  maintenance  system.  For  example,  an 
engineer  may  state  a  specific  processing  time  requirement  on  a  system 
subcomponent  in  order  to  cover  a  near-real-time  requirement  for  the  entire 
system.  If  KBRA  is  made  aware  of  this  relationship,  it  will  remind  an 
engineer  of  the  connection  when  a  review  of  the  processing  time  requirement 
is  requested.  In  addition,  KBRA  will  know  that  in  the  event  an  engineer 
removes  the  near  real  time  requirement,  the  engineer  must  reconsider  the 
processing  time  requirement  since  its  support  is  no  longer  present. 

KBRA  propagates  information  by  running  rules  or  procedural  attachments 
when  the  state  of  the  evolving  system  description  changes.  For  example, 
when  an  external  agent,  such  as  a  radar  system  interacting  with  an  air 
traffic  control  system,  is  declared,  KBRA  automatically  adds  any  known 
output  (such  as  radar  messages;  of  the  agent  to  the  input  list  for  the  system 
being  described. 

Checks  for  consistency  include  looking  for  data  flow  anomolies,  invoking 
user-defined  constraints  on  potentially  competing  requirements,  and  looking 
for  violation  of  physical  laws.  Items  which  must  be  specified  are  often 
interrelated.  When  this  occurs,  KBRA  established  constraint  networks  which 
track  dependencies  and  maintain  logical  consistency  (unit  propositional 
resolution)  among  the  items. 
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One  example  of  such  consistency  checking  is  illustrated  in  the  figure.  What 
is  shown  is  a  partial  decomposition  of  an  air  traffic  control  system.  The  sweep 
rate  of  the  radar,  the  initiation  time  of  the  tracker,  and  the  need  to  begin 
tracking  airplanes  before  they  enter  a  controlled  area  are  connected  with  a 
simple  "distance  is  rate  times  time"  formula.  If  KBRA  knows  of  thi6 
connection,  it  will  enforce  it  when  an  engineer  makes  explorations  attempts 
to  specify  requirements.  In  the  event  that  the  engineer  over-specuies  the 
requirements  participating  in  the  formula,  KBRA  will  detect  inconsistent 
requirements  and  if  possible  automatically  resolve  the  contradiction. 

In  addition  to  assistant  behavior,  and  when  appropriate,  KBRA  takes  the 
initiative  and  plays  a  more  active  role  in  requirements  generation  based  on  its 
expectations  about  the  system  being  described.  KBRA  completes  partial 
descriptions  (e.g.  completes  data-flow),  critiques  decisions  made  (e.g.  the  work 
is  not  complete,  values  chosen  are  not  reasonable  in  this  context,  values  are 
inconsistent  with  other  requirements,  requirements  contain  redundancies), 
incorporates  default  values  and  default  data  flow  properties,  and  automatically 
classifies  objects  based  on  interrelated  required  properties. 

Knowledge -Based.  Editing  of  Multiple  Viewpoints 

Multiple  viewpoints  are  important,  certainly  for  engineers’  stylistic  choices, 
but  more  significantly  because  software  description  cannot  be  completely 
visualized  from  any  one  coherent  projection.  We  have  investigated  and 
incorporated  standard  system  description  concepts  (e.g.,  data  flow,  state 
transition).  The  development  of  these  concepts  has  been  important  knowledge 
engineering  work  within  the  requirements  domain.  While  the  methodologies 
associated  with  these  concepts  are  frequently  inadequate  for  complete 
requirements  work,  the  notations  used  are  a  particularly  useful  means  of 
communication  between  engineers  and  for  helping  people  to  get  a  handle  on 
problem  complexity.  A  part  of  our  work  has  been  to  formalize  these  concepts 
in  an  integrated  machine-useable  manner.  For  example,  each  of  the  KBRA 
screen  images  below  displays  different  information  about  the  operational  mode 
of  an  air  traffic  control  system.  Each  in  their  own  wey  provides  a  user  with  a 
global  perspective  on  the  wor’;  he  or  she  has  done. 
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Hence,  multiple  viewpoints  are  a  form  of  paraphrasing  which  can  help  a 
user  manage  the  complexity.  We  refer  to  the  viewpoints  which  can  be  edited 
as  "presentations".  This  editing  is  knowledge-based.  In  other  words,  inference 
based  on  knowledge  about  the  presentation  type  and  about  requirements 
relationships  is  used  m  order  tc  set  KBRA  expectations,  provide  feedback,  and 
maintain  consistency  during  the  editing  process. 

Comrik’iiry  Knowledge 

KBRA  embodies  and  interacts  with  community  knowledge.  Community 
knowledge  is  domain-specific  knowledge  about  solutions  to  particular 
requirements  level  problems.  It  can  include  solutions  ranging  from 
decomposition  strategies,  to  typical  data,  to  relationships  between  performance 
characteristics.  In  general  it  is  this  knowledge  which  sets  expectations  for 
requirements  work  and  allows  KBRA  to  critique  the  work  that  an  engineer 
performs  Except  m  rare  cases,  requirements  engineers  take  advantage  of  the 
knowledge  and  experience  they  have  in  specifying  similar  systems.  Our 
perception  is  that  this  will  continue  to  be  the  case  in  the  forseeable  future  as 
most  new-  system  development  will  continue  to  use  large  segments  of 
conventional  components.  This  suggest?  that  there  is  a  tremendous  potential 
for  the  reuse  of  stereotypical  solutions.  This  knowledge  can  be  accessed  by 
engineers  and  reused  to  solve  new  problems.  In  addition,  it  allows  KBRA  to 
perform  analysis  on  the  requirements  that  an  engineer  enters. 


KNOWLEDGE  REPRESENTATION 

The  highest  level  view  into  KBRA  reveals  two  major  architectural  disciplines 
and  an  implementation  of  those  disciplines  with  a  hybrid  knowledge 
representation  system.  The  first  architectural  discipline  is  the  separation  of 
empty  machine  from  knowledge-base  This  is  the  discipline  fundamental  to 
expert  system  work.  Within  KBRA  it  has  meant  the  explicit  codification  of 
requirements  formalisms  such  as  data,  activities,  events,  states,  performance 
character s ties,  other  non-functional  requirements  and  the  codification  of  an 
evolving  system  description  within  hierarchies  of  such  objects. 

The  second  architectural  discipline  is  that  of  a  presentation-based  interface. 
That  is  to  say  we  have  taken  a  systems  approach  to  building  an  interface 
which  importantly  provides  multiple  viewpoints,  associative  retrieval,  and 
know! edge- based  editing  of  the  evolving  system  description.  This  systems 
approach  separates  presentation  of  requirements  knowledge  (e.g.,  data  flow 
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diagram,  state  transition  diagram)  from  representation  of  requirements 
knowledge  (e.g.  a  tracker  is  a  kind  of  air  traffic  control  function  which 
maintains  track  block  records  for  all  aircraft  within  the  airspace).  As  we 
mentioned  earlier,  presentation  knowledge  is  itself  an  important  component  of 
knowledge  about  requirements.  Among  other  things,  KBRA  has  codified  this 
knowledge,  identified  commonalities  among  presentations,  and  established  the 
connections  between  presentation  and  requirements  representation.  Readers 
interested  in  more  information  about  presentation-based  interfaces  are 
referred  to  [Ciccarelli], 

Socle  (a  homonym  derived  from  Structured  Object  and  Constraint  Language 
Environment)  [Harris]  is  the  knowledge  representational  tool  which  is  used 
for  implementing  the  architectural  disciplines.  Socle  is  a  hybrid  system  (with 
FRL  [Roberts  and  Goldstein]  and  Constraint-based  Languages  [Steele]  as 
ancestors).  It  supports  both  object-oriented  and  constraint-based  programming 
styles.  The  Air  Traffic  Control  diagram  illustrated  in  the  earlier  figure  is  an 
abstraction  showing  a  mix  between  description  through  object  specification 
and  constraint  specification.  Within  KBRA  this  information  iB  collected  from 
an  engineer  through  his/her  editing  of  presentations  of  high  level  system 
description  (e.  g.  decomposition,  spread  sheet  relationship)  and  is  propagated 
to  internal  representations  of  the  diagram  abstraction.  Once  this  information 
is  entered,  it  is  represented  as  Socle  objects.  All  subsequent  inference  based 
on  these  objects  is  mediated  by  Socle. 


RELATED  EFFORTS 

There  are  several  research  efforts  that  are  related  to  KBRA. 

The  work  most  closely  related  to  our  own  is  that  of  the  Programmer’s 
Apprentice  (PA)  [Rich,  Schrobe]  at  MIT.  Specifically,  a  new  Requirements 
Apprentice  (RA)  [Rich.Waters]  beachhead  has  very  recently  been  started.  The 
RA  is  like  the  KBRA  in  that  it  attempts  to  exploit  expectations  about 
requirements  statements  in  order  to  actively  assist  a  requirements  analyst. 
KBRA  and  RA  have  different  focus  however.  The  KBRA  concern  for 
informality  and  requirements  acquisition  will  probably  not  be  seen  in  the  RA 
In  addition,  the  two  systems  differ  in  their  posture  toward  machine 
understanding  of  requirements.  KBRA  takes  a  modest  step  forward  in 
formalizing  this  understanding;  the  RA,  as  a  next  generation  automatic 
programming  component,  will  aim  at  a  deeper  formalization.  Throughout  our 
effort  we  have  worked  with  members  of  the  PA  staff  to  the  mutual  benefit 
of  both  efforts. 


Another  related  effort  is  ISI’s  SAFE  [Balzer,  Goldman,  Wile],  This  effort 
made  the  significant  contribution  of  identifying  problems  of  informality  in 
requirements  specification  and  of  beginning  the  process  of  attacking  these 
problems.  The  SAFE  approach  is  very  different  from  KBRA’ 8  approach. 
Specifically,  SAFE  emphasizes  natural  language  and  total  automation  of  the 
informal  to  formal  transformation.  On  the  other  hand,  KBRA  emphasizes 
requirements  acquisition  through  graphical  and  text  modes  and  the 
semi-automatic  transformation  of  informal  to  formal  description. 

RML  [Greenspan]  is  a  language  for  requirements  modeling.  In  part  its 
inspiration  is  the  SADT  model.  SADT  is  a  software  design  methodology  that 
emphasizes  dual  decomposition  of  systems  from  activity  and  data  perspectives. 
RML  supplies  the  semantics  behind  an  SADT  diagram.  Its  formalization  of 
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requirements  constructs  (through  imkuge  to  first  order  logic)  is  an  important 
contribution  to  machine  understar a:r.£  cl  requirements  analysis. 

PAlSLey  iZavel  is  an  example  of  a  formal  requirements  language  for  a 
narrow  application  area,  specifically  real-time  distributed  systems.  As  a  narrow 
domain  application  generator  it  is  not  specifically  addressing  the  goals  of 
KBSA  However,  in  the  long  term  we  anticipate  the  inclusion  of  several  such 
application  generator  capabilities  within  a  requirments  facet. 

Within  the  KBSA  itself,  KBRA  i^  related  to  both  the  specification  facet  and 
the  performance  facet.  The  output  of  KBRA  is  a  set  of  formal  requirements 
which  have  been  checked  for  consistency  to  some  level  of  completeness.  These 
requirements  are  then  handed  of!  to  the  specification  assistant  where 
additional  manual  and  automata  manipulation  take  place  as  a  formal 
specification  is  produced.  To  a  first  oppmxiRiation,  KBRA  is  more  about 
acquisition  of  requirements  and  trie  movement  from  informal  to  formal 
specification  The  concerns  of  the  specif  ition  assistant  are  more  with 
verification. 

The  role  of  the  KBSA  performance  assistant  is  to  select  appropriate 
transformations  base"1  on  knowledge  of  performance  '-haracteristics  associated 
with  choices  Thy  .'••i  -ctm  car  provide  efficient  solutions  at  the  requirements 
level  t;  ..'  c the  imp-ementation  level  (where  the  performance  facet  prunes 
the  tr-  -sible  implementations  as  derived  from  formal  specification).  For 

exam,  a.  vsi-reiiabi.ity  trade-offs  affect  the  choice  of  a  tracker  algorithm  for 
an  am  tra/Tc  control  system  Jt  is  important  that  these  trade-offs  be 
considered  a*  the  requirements  lew!  tr  ensure  that  solutions  are  feasible. 
KBRA  certain?  surf,  performanc  -.naiysi.-  capabilities  at  the  requirements 
level  lru  uded  arc  automatic  specialization  of  algorithms  in  order  to  satisfy 
collect :or.«  of  requirements,  and  cons.stency  checks  between  potentially 
competing  requirement  or.  timu:g  accuracy,  or  cost 


CONCLUSION 

KBRA  addressee  the  machine-manager..- ‘-■nt  of  requirements  activities.  This  is 
accompli'-  ,ed  by  prow-ding  analysis  and  presentation  support  to  the  process  of 
incrementally  developing  a  formal  se'  of  requirements  for  a  complex  system. 
We  believr  we  have  taken  the  neceso.w  first  step  toward  supporting  the 
acquis.tr ri  of  requ.mments  ai.d  thus  are  providing  KBSA  with  an  ability  to 
handle  complex  programming-in  -  the  large  systems  that  are  envisioned  for  the 
forscv’tve  future 

Future  directions,  beyond  the  work  we  envision  for  this  first  prototype.could 
include  1  >  development  of  a  requirements  process  model,  2>  building  a 
multi-user  environment  which  addresses  issues  such  as  configuration 
management  partitioning  of  requirements  tasks,  and  the  role  of  an 
intelligent  assistant  as  an  active  agent  working  with  several  human  agents, 
and  the  addition  of  requirements  level  validation  tools  such  as  general 
purpose  and  special  purpose  rapid  prototyping  capabilities  In  our  own  efforts, 
we  have  conducted  a  preliminary  .rivespgntion  into  using  Socle  as  an 
executable  requirement?  language  for  rapid  prototyping  Results  of  this 
investigation  have  been  very  incouragmg. 

The  current  KBRA  prototype  is  a  demonstration  of  many  of  the  essential 
featun  ■  of  the  i.hitna*"  KBSA  r-  --  y-mneuts  assistant.  It  is  designed  to 
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support  the  requirements  engineer  beginning  at  the  initial  phase  of 
requirements  work  and  continuing  through  to  document  preparation.  In 
using  KBRA,  an  engineer  makes  the  commitment  to  working  on-line  not 
on-paper.  The  reward  for  this  commitment  is  that  the  decisions  made  and 
their  associated  justifications  are  not  lost,  but  rather  become  part  of  the 
KBSA  environment  to  be  available  and  used  throughout  the  entire  software 
Ufe  cycle. 
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Overview  of  the  Knowledge-Based 
Specification  Assistant 


W.  Lewis  Johnson 
USC/Information  Sciences  Institute 
4676  Admiralty  Way,  Marina  del  Rey,  CA  90292 

Abstract 

In  order  for  specifications  to  be  used  effectively  in  software  development,  we  need  tools 
to  do  the  following  things:  a)  assist  in  developing  the  specification;  b)  analyze  and 
evaluate  the  specification;  and  c)  explain  the  specification.  The  Knowledge-Based 
Specification  Assistant  (KBSA)  is  designed  to  provide  assistance  along  these  three 
dimensions.  This  system  aids  people  in  specifying  programs,  by  allowing  them  to  record 
their  initial  views  of  system  requirements  and  to  gradually  transform  them  into 
complete  specifications.  Symbolic  evaluation  and  simulation  tools  are  provided  so  that 
the  specifier  can  run  the  specification  as  a  prototype,  and  so  that  unexpected 
implications  of  statements  in  the  specification  can  be  detected.  Explanation  facilities  do 
retrievals  from  the  specification  database  in  response  to  user  queries,  and  generate 
natural-language  answers  and  summaries  in  response  to  the  queries.  An  overview  of 
each  of  these  facilities  will  be  presented  in  this  paper. 


1.  Introduction 

Software  deveiopm  mt  an-.'  maintenance  are  complex,  time-consuming,  and  error-prone 
processes.  Software  dec  elopers  must  decide  what  an  application  is  supposed  to  do, 
implement  the  application,  and  then  somehow  determine  whether  or  not  the 
implementation  really  does  a  hat  was  intended.  Maintainers  must  try  to  understand 
what  the  application  does,  what  it  is  suppos<  d  to  do,  and  then  decide  how  to  change 
one  or  the  other  or  both.  At  eu"h  stage  errors  and  misunderstandings  may  arise;  as  the 
application  is  revised  and  maintained,  the  potential  for  errors  and  misunderstandings 
becomes  that  much  greater 

Research  in  automatic  programming  !•>.  15]  and  transformation-based  implementation 

'IS,  v.  -i  has  a'  ■  :  v i  .0  reduce  the  complexity  of  the  software  process,  by  bridging 

the  ca,.  ’•  vec;:  specification  and  implementation.  Software  is  developed  not  by 
writing  ':  tii  nut  by  writing  formal  specifications.  These  specifications  are  automatically 
or  semi-automatically  transformed  into  executable  code.  As  a  result,  people  can  be 
more  confident  that,  the  code  really  implements  the  specification.  Maintenance  can  be 
[  rformed  by  changing  the  specification  as  needed,  and  deriving  ■*  new  implementation 
from  the  modified  specification. 

The  Knowledge-Based  Software  Assistant  effort  [ 1 3]  has  embraced  the  notion  of 
specification-based  software  development.  At  the  same  time,  though,  it  L  recognized 
that  automatic  programming  and  transformation-based  implementation  leave  major 
questions  unanswered.  First,  how  is  the  specification  developed  in  the  first  place’ 
Specifiers  do  not  just  sit  down  and  write  a  specification;  it  Lakes  time  to  work  out  all  of 
the  details  of  what  an  application  should  do.  Second,  how  do  we  ensure  that  people 
really  understand  what  a  specification  says’  It  is  difficult  to  wade  through  the 
complexity  of  a  typical  specification,  and  recognize  where  assumptions  and  design 
decisierm  v. ni.uie.  The  Km >  w I f d gt- Based  Specification  Assistant  project  attempts  to 
address  tire- 1  uucst ions,  by  providing  aid  in  developing,  evaluating,  and  understanding 
specifications. 

The  A-" ,-ifif  at  :■  •  .  Assistant  is  motivated  by  the  recognition  of  two  key  aspects  to 
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specification  development: 

•  specification  development  is  a  kind  of  design  process: 

•  specification  development  is  an  evolutionary  process. 

When  specifiers  write  specifications,  they  have  a  set  of  goals  in  rninu  for  the  specified 
system  to  achieve.  They  attempt  to  design  a  specification  wnlch  determines  precisely 
what  the  application  should  do  to  try  to  meet  those  goals.  Complexity  arises  as  the 
specifier  identifies  exceptions  to  goals,  resolves  conflicts  between  goals,  or  reformulates 
goals  into  new  ones  that  .are  easier  to  implement.  At  the  sanv5  time,  the  specifier's 
conceptual  model  of  the  domain  and  the  application  constantly  evolves;  the  specifier 
may  discover  new  goais  :>  be  addressed,  or  change  his  or  her  mind  about  previously 
stated  goals. 

The  Specification  Assistant  aids  specification  development  by  allowing  people  to 
record  their  initial  views  of  system  requirements  and  helping  them  to  transform  this 
initial  descriptions  into  complete  specifications.  It  also  provides  specifers  with  tools  for 
revising  the  specification  in  meaningful  ways;  the  specifier  can  describe  what  is  wrong 
with  the  specification,  and  the  Specification  Assistant  can  then  change  the  specification 
to  correct  the  flaw.  A  record  is  kept  of  how  the  specification  was  constructed  and 
modified;  this  aids  subsequent  understanding  and  maintenance  of  the  specification. 

In  order  to  develop  a  specification  properly,  a  specifier  must  constantly  analyze  and 
evaluate  the  specification.  The  specifier  must  make  sure  that  the  specification  says 
what  is  supposed  to  say;  the  specifier  must  also  check  if  the  specification  is  incomplete 
or  unimplementable,  and  refine  the  it  as  necessary.  To  assist  this  process,  IvBSA 
provides  tools  for  analyzing  and  evaluating  specifications.  The  system  can  symbolically 
evaluate  the  specification,  or  run  simulations  on  test  data.  It  can  analyze  the 
specification  for  various  kinds  of  inconsistency  or  incompleteness. 

KBSA  also  has  facilities  for  explaining  specifications.  When  fully  implemented,  these 
facilities  will  include  showing  the  specification  from  different  viewpoints  and  along 
different  dimensions,  and  paraphrasing  the  formal  specification  notation  into  English. 


These  facilities  ar<*  intt  nded  as  a  means  ior  c.  nunumcating  a  model  of  the  specified 


svstea.  t<>  :  he  user. 


'J.  Architecture  of  the  Specification  A'-"Ktant 

Figure  5  > ! :  ( ■  >  the  high-level  <j  tit  a- How  structure  of  the  Knowledge-Based 
s , ■  e  ■  i :*i cut F  i.  .Assistant.  cr  KJdi-A.*  !u  thK  migrant.  boxes  represent  data  maintained  or 
generated  by  tie-  system:  ellipses  :  "pi 'Sent  processes  within  the  system;  triangles 
represent  inputs  from  th-  user.  K\  -rythip.g  inside  the  large  box  is  internal  to  the 


At  th" 


rvstem  w 


•  --ss.  the  user  describes  the  domain  in  which  the  specified 
u’ lines  the  initial  requirements  to  the  system.  The  domain 
va'emer.ts  describing  objects,  relations,  and  events  in  the 
""incuts  at"  high-level  gist  descriptions  of  the  desired  behavior 
,;"ied.  in  tiie  form  of  constraints  and  sequences  of  events  and 
:  r<  ‘-no.-red  into  the  Specification  Database,  a  repository  of 


•i* ions  that  ai<-  currently  under  development,  or  which  have 


<  Trr-  requirem-nts  and  domain  mode!  must  be  entered  directly  by  the  user. 

11  w*  vtr.  v-  ■  are  in  the  process  of  building  a  translator  which  can  take  the  domain 
m  ml-  u.-ed  by  th-  Km  w i-dgt--Based  Requirements  Assistant  [  1 7]  and  translate  them 

f . i i - 1 .  This  will  allow  the  Requirements  Assistant  and  the  Specification  Assistant  to 
:.ou-  t  ia  -mm  mo  jel  ->i’ t  li-v  domain  f  -ing  specified. 

<  >:.-••  t  !;■•  sp-eifmation  MateiiiMits  have  been  entered  into  KBS  A.  they  cat.  m  ctiiua.t 
r-fined  and  r- .ised.  Tims-  refinement?-  and  '•“visions  are  accomplished  using  Kigh -level 
editing  commend;1.  High-level  editing  commands  modify  the  sped fi cut i  m  in  m-  ier  to 
accomplish  Swim-  desired  ciiange  in  tin-  semantics  of  the  specification.  A  him.  re  of  the 


Throughout  the  rest  of  this  document,  wt*  will  take  "KBSA"  to  refer  to  the  Knawleuge-Based 
Spe  ificatir,n  Assist, iii i .  not  the  Knowledge-Rased  Software  .Assistant.  The  ambiguity  of  the  acronym  u- 
-, iiifortur.ru  <■ 
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Spec  &  Development 

Evaluation  of  specification. 
Overview  of  pending  work 

Triangles  User  input 

Doves-  Data 

['!iipsf"=  Processes 

Figure  2-1:  Overview  of  Specification  Assistant 
editint;  steps  and  their  effects  are  recorded  in  the  specification  database. 


In  order  for  the  specifier  to  better  understand  a  specification  as  it  is  being  developed, 
a  set  of  analysis  and  evaluation  tools  are  provided.  These  tools  analyze  the  specification 
to  make  sure  that  it  is  semantically  consistent,  and  identify  places  where  further 


] 
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specification  development  is  required.  They  also  provide  the  means  for  executing  the 
specification  and  observing  its  behavior.  The  analysis  toois  can  be  invoked  directly  by 
the  user;  they  are  also  automatically  invoked  by  other  components  of  KBS  A,  such  as 
the  specification  editor,  in  order  to  retrieve  information  about  the  specification.  The 
analysis  tools  add  information  to  the  specification  database,  where  it  is  available  for 
inspection  by  other  components  of  KBSA. 

Finally,  the  Specification  .Assistant  contains  a  Specification  Explainer  module.  The 
Specification  Explainer’s  current  function  is  to  paraphrase  the  specification  in  English, 
making  it  easier  to  understand.  However,  when  users  request  paraphrases  of  parts  of 
specifications,  they  usually  have  a  particular  question  in  mind  about  the  specification. 
We  plan  to  significantly  extend  the  power  of  the  Specification  Explainer  so  that  it  can 
answer  general  user  queries  about  the  specification. 

3.  Specification  Development 

We  will  now  look  at  how  specifications  are  built  up  incrementally  in  KBSA.  We  will 
examine  the  following  issues: 

•  high-level  editing  commands,  their  purpose  and  function, 

•  reusing  specifications  using  specification  views,  and 

•  how  KBSA  can  guide  the  user  in  selection  of  editing  commands. 

At  this  stage  ir.  the  implementation  of  KBSA  our  repertoire  of  high-level  editing 
commands  are  fairly  well  developed.  The  view  mechanisms  and  user  guidance 
techniques  are  at  fairly  early  stages  at  this  point. 

We  are  current  working  on  two  applications  as  test  cases  for  KBSA:  a  patient- 
monitoring  system  and  an  air-traffic  control  system.  The  examples  in  this  paper  will 
focus  on  the  patient-monitoring  system.  A  number  of  researchers  have  used  this 
application  as  an  example  specification  problem.  A  short  description  of  it,  taken  from 

[9],  follows. 

A  patient-monitoring  system  is  required  for  a  hospital.  Each  patient  is 
monitored  by  an  analog  device  which  measures  factors  such  as  pulse, 
temperature,  blood  pressure,  and  skin  resistance.  The  program  reads  these 


factors  on  a  periodic  basis  (specified  for  each  patient)  and  stores  these  factors 
in  a  data  base.  For  each  patient,  safe  ranges  for  each  factor  are  specified 
(e.g.,  patient  X's  safe  temperature  range  is  98  to  99.5  degrees  Fahrenheit'.  If 
a  factor  falls  outside  of  a  patient’s  safe  range,  or  if  an  analog  device  fails,  the 
nurse's  station  is  notified. 

3.1.  High-Level  Editing  Commands 

To  illustrate  incremental  specification  development  and  high-level  editing  commands, 
we  will  start  out  with  a  high-level  specification  of  the  patient-monitoring  system,  and 
show  how  this  specification  is  progressively  elaborated.  This  example  will  go  into  some 
detail,  so  that  the  reader  can  see  exactly  how  the  process  is  carried  out. 

Figure  3-1  shows  the  high-level  Gist  specification  for  the  patient-monitoring  system. 
We  will  not  go  into  the  details  of  Gist  syntax  here;  the  reader  may  refer  to  Appendix  1 
for  a  description  of  Gist.  However,  to  make  the  specification  easier  to  understand,  we 
include  in  Figure  3-2  the  English  paraphrase  of  this  specification  generated  by  KBSA’s 
English  Paraphraser,  a  part  of  the  explanation  component  of  IvBSA. 

An  important  point  to  observe  about  this  specification  is  that  it  describes  the  patient 
monitor's  behavior  in  a  highly  idealized,  non-operational  manner.  For  example,  the 
notlf y-nurse  demon  of  the  monitor  notifies  the  nurse  simply  by  asserting  the 
knovs-unsaf e  relation  between  the  nurse  and  the  patient.  It  performs  this  action 
whenever  the  safe-signs  relation  is  false  for  a  patient.  Some  of  the  behavior  of  the 
application  and  the  environment  is  underspecified.  The  relation  safe-signs  currently 
is  described  as  changing  in  a  random  or  unspecified  wav.  In  the  complete  specification 
safe-signs  will  not  be  random  at  all,  but  wili  be  computed  from  the  patient’s  vital 
signs.  A  motivation  and  analysis  of  these  different  kinds  of  specification  idealizations 
appears  in  [  14] .  The  specification  developer  must  transform  this  initial  specification 
into  a  concrete,  operational  specification. 

The  specifier  might  start  out  by  filling  in  some  of  the  definitions  of  the  terms  in  the 

‘  Hus  information  is  captured  in  the  definition  of  the  relation  as  Implicit,  which  means  that  the 
relation  randomly  becomes  true  and  false  over  time,  as  a  consequence  of  some  process  that  the 
specification  does  not  describe 


{type  vital-sign  =  { ’blood-pressure ,  ’temperature), 
type  pvalue  =  real, 
type  day-time, 
type  patient  with  { 

relation  readlngC  vital-sign,  pvalue)), 
static  singleton  type  nurse, 


relation  medical-entry  (monitor ,  patient,  vital-sign,  pvalue, 

day-time) , 

relation  knows-unsafe (nurse .  patient), 
implicit  relation  safe-signs (patient) , 
implicit  relation  tlme-to-record-slgns (patient)  , 

Implicit  singleton  relation  current-time  (day-time)  , 


static  singleton  type  monitor  with  { 
demon  notlfy-nurse  [  patient] 
when  -'-safe-signs  (patient) 
do  insert  knows-unsafe (nurse ,  patient), 
demon  record-signs  [  patient] 

when  tlme-to-record-slgns (patient) 
do  parallel  loop  on{v  I  vital-sign)  do 

Insert  medical-entry (monitor ,  patient,  v, 

reading(patient, v,?) , 


) 


current-time  (?) ) ) 


Figure  3-1:  A  high-level  specification  of  the  Patient- Monitoring  System 

specification,  such  as  safe-signs,  safe-signs  is  true  of  a  patient  if  and  only  if  all 

of  the  patient's  vital  signs  are  within  some  safe  range.  The  specifier  must  therefore 

refine  the  definition  of  safe-signs,  and  define  any  new  terms  that  are  introduced  in 

the  process.  The  resulting  definitions  might  look  like  the  following: 

implicit  relation  safe-signs (patient)  iff 

for  all  v  1  vital-sign  II  safe-vital-sign (patient ,  v) ; 
implicit  relation  saf e-vltal-slgn (patient ,  v I  vital-sign)  iff 

inside-range (reading (patient ,  v,  ?) ,  saf e-range (patient ,  v,  ?)); 
implicit  relation  saf e-range (patient ,  vital-sign,  range-of-pvalue) ; 
implicit  relation  Inside-range (pvalue ,  range-of-pvalue); 
type  range-of-pvalue  Instances  are  sequences  of  pvalue 


KBSA  provides  development  assistance  at  this  stage  of  the  process  primarily  by 
providing  structure-editing  commands  that  the  user  can  employ  to  fill  oui  these 
definitions,  for  example,  the  Add  Random  Relation  command  inserts  an  implicit- 


The  items  in  this  specification  are  vital-signs,  pvalues,  day-times,  patients,  a  nurse  and 
a  monitor. 

There  is  only  one  monitor.  The  identity  of  the  monitor  never  changes.  Notify-nurse 
and  record-signs  are  demonic  actions  of  a  monitor.  The  RECORD-SIGNS  demon 
executes  a  parallel  loop  when  time-to-record-signs  is  true  of  a  patient.  The  demon  loops 
over  each  vital-sign  V  and  inserts  a  medical-entry  consisting  of  a  monitor,  a  patient,  a 
vital-sign,  a  pvalue  (which  is  related  to  the  v  and  a  patient  by  the  reading  relation)  and 
a  day-time  (which  is  the  current-time).  The  NOTIFY-NURSE  demon  asserts  a  knows- 
unsafe  relation  when  safe-signs  isn’t  true  of  a  patient. 

There  is  only  one  nurse.  The  identify  of  the  nurse  never  changes. 

There  are  patients.  Reading  is  an  owned  relation  of  the  patient.  Readings  are 
relations  that  involve  a  patient,  a  vital-sign  and  pvalue. 

There  are  day-times. 

Ah'  pvalues  are  (real)  numbers. 

There  are  vital-signs.  The  only  vital-signs  are  blood-pressure  and  temperature. 

There  is  only  one  current-time.  The  current-time  is  a  predicate  over  day-times  which 
.manges  in  a  random  or  unspecified  way. 

Safe  -signs  is  a  predicate  over  patients  which  changes  in  a  random  or  unspecified  way. 

Medical-entries  are  relations  that  involve  a  monitor,  a  patient,  a  vital-sign,  a  pvalue 
and  a  day-time. 

Knows-unsafes  are  relations  that  involve  a  nurse  and  a  patient. 

Figure  3-2:  An  English  paraphrase  of  the  specification  in  Figure  3-1 


relation  template  into  the  specification,  which  the  user  can  then  fill  out.  The  Add 
Definition  to  Relation  command  checks  to  make  sure  that  a  relation  is  declared  implicit, 
and  then  inserts  a  user-supplied  predicate  into  the  iff  field  of  the  the  definition.  The 
user  must  do  the  hulk  of  the  work  of  defining  the  terms  at  this  point;  KitSA  does  not 
attempt  to  guess  the  definitions  of  terms. 

Now  that  the  terms  in  the  specification  are  more  fully  defined,  some  initial  steps 
toward  operationally  can  be  made.  For  example,  the  user  may  attempt  to  clarify  what 
data  the  monitor  is  allowed  to  access.  The  definition  of  the  monitor  currently  makes 
use  of  the  reading  relation,  a  property  of  patients;  it  relates  patients,  types  of  vital- 
signs,  and  values  of  vital-signs.  The  specifier  must  decide  whether  the  monitor  should 
actually  be  capable  of  observing  the  patients’  vital  sign  readings,  and  if  not  how  the 
vital  sign  readings  are  to  be  determined  or  computed.  Also,  it  is  not  clear  from  the 
specification  whether  or  not  the  monitor  is  responsible  for  determining  whether  or  not 
safe-signs  is  true.  The  specification  simply  states  that  safe-signs  is  true  when 
the  patients'  vital  signs  are  within  a  given  range. 

We  have  extended  the  semantics  of  Gist  to  indicate  data  boundaries.  Each  type 
definition  implicitly  defines  a  data  boundary:  any  definition  inside  of  the  with  clause  of 
a  type  is  regarded  as  internal,  and  everything  else  is  considered  external.  The  user 
might  start  by  reorganizing  the  specification  to  take  data  boundaries  into  account. 
Currently  the  only  definitions  internal  to  the  monitor  are  the  demons  notlf y-nurse 
and  record-signs,  describing  what  the  monitor  does.  We  can  also  move  data 
definitions  inside  of  the  monitor  definition  if  we  wish.  High-level  editing  commands  can 
lv  used  to  perform  this  task.  One  command.  Make  Owned  Copy,  makes  a  copy  of  a 
definition  local  to  a  type,  and  modifies  all  references  to  the  definition  within  the  type  to 
refer  to  the  copied  definition.  We  can  use  this  to  define  a  new  relation  within  the 
monitor,  computed-saf e-slgns.  The  same  technique  can  be  employed  to  other 
terms  that  tfm  monitor  definition  refers  to. 

The  next  step  is  to  determine  how  the  monitor  is  to  observe  the  reading  relation. 
This  is  achieved  by  introducing  a  new  type  called  device.  Devices  will  have  a  new 


relation,  called  device-reading,  whose  values  correspond  to  the  patients'  readings. 
Every  reference  that  the  monitor  makes  to  reading  should  be  redirected  to  r^fer  to 
device-reading.  These  changes  are  performed  by  the  high-level  editing  command 
Splice,  described  in  [10].  Splice  performs  the  changes  listed  above;  it  also  defines  a 
mapping  between  patients  and  devices,  so  that  the  monitor  knows  which  device  to  read. 
The  resulting  definitions  of  monitor  and  device  are  as  follows, 
type  device  with  < 

singleton  relation  assoc-patlent (patient) ; 

Implicit  relation  device-reading (vital-sign ,  pvalue)  iff 
reading (assoc-patlent (self ,  ?),  vital-sign,  pvalue) 

> ; 

invariant  for  all  device  I  I 

count(any  patient  II  assoc-patlent (device ,  patient))  =  1; 

static  singleton  type  monitor  with  { 

Implicit  relation  computed-saf e-slgns (patient)  Iff 

for  all  v  I  vital-sign  II  computed-saf e-vltal-slgn (patient ,  v) ; 

Implicit  relation  computed-saf e-vltal-slgn (patient ,  v I  vital-sign) 
Iff  lnslde-range (devlce-readlngCassoc-patlent (? .patient) ,v,?) , 

safe-range (patient ,  v,  ?)); 

demon  notlfy-nurse [patient] 

when  ~computed-saf e-slgns (patient) 
do  Insert  knows-unsafe (nurse ,  patient); 

demon  record-signs [patient] 

when  tlme-to-record-signs (patient) 
do  parallel  loop  on  {v  |  vital-sign} 

do  Insert  medical-entry (monitor ,  patient,  v, 

devlce-readlng((assoc-patlent(?,  patient),  v,  ?) , 
current-time  (?) ) 

> 

As  we  see  in  this  example,  high-level  editing  commands  allow  specifiers  to  describe 
changes  to  specifications  at  a  more  conceptual  level.  The  specifier  reasons  about  what  is 
wrong  with  a  given  version  of  a  specification,  e.g.,  a  type  observes  data  that  should  not 
be  observable.  He  or  she  then  selects  a  high-level  editing  commands  which  implements 


of  individual  chances  t. 


.  hange.  The  ••ditinu  ectninand  may  ;  :~r.  •  •  rf  >nn  a  ..umber 
;  spr-’dlratio;..  The  spe  ‘ifier  a-  au-  ::  '  i . •  •  i  to  be  t  m-d  with  how  exactly  •  :;<• 
unge  is  performed.  Furthermore.  i-  -Icai  err.  •:>  ar  r. voided,  resulting  in  a 
kf.-;t’.  i  n  that  is  men  lively  to  he  v.. 

i  are  currently  over  twenty-fiv«  high-level  editing  commands  imj  demented  in 

KB -'A:  these  in  turn  make  use  of  a  number  <  f  >wer-!ev<*i  <•  mmands.  We  are  beginning 
rear;,  the  point  where  one  car.  perku extended  specification  development  sessions 
u.-ing  IvBSA.  However,  we  expect  that  the  editing-command  catalog  will  continue  to 
grow  .  a  i  st  anti  ally  tvs  tic  h  '.f.opm.-ie  KBSA  continues. 


3.'J .  Mews 

.Ait hough  tic  major  thrust  of  our  assistance  for  specification  development  is  in  the 
area  <  :d.  :  -l  —  vi  editing  commands,  we  are  also  doing  work  in  a  number  of  other  areas. 

Oi  ••  area  of  research  is  directed  toward  breaking  away  from  the  linear  model  of 
specification  development  described  above.  Rather  than  start  with  an  empty 
sp"cification  and  building  it  up  one  step  at  a  time,  we  wish  to  be  able  to  build  a 
specification  by  extracting  specification  components  from  a  common  library,  and 
elaborating  them  in  parallel.  The  following  discusses  some  of  the  efforts  currently 
underway  in  this  regard. 

Idle  KBSA  paradigm  for  specification  development  involves  using  a  model  of  the 
target  domain  as  the  starting  point  for  building  the  specification.  One  describes  the 
entities  ip  the  domain,  such  as  patients  and  nurses,  what  their  properties  are.  and  what 
their  behavior  is.  This  domain  model  is  used  as  a  basis  for  describing  what  the 
application  should  do.  For  example,  once  we  have  described  what  it  means  for  a 
patient's  condition  to  be  regarded  as  safe,  we  can  use  this  to  define  how  the  patient 
monitor  reacts  to  unsafe  patient  conditions.  However,  there  is  little  that  KBSA  can  do 
‘before  the  domain  model  is  defined.  In  the  above  scenario,  the  user  had  to  supply 
definitions  for  relations  like  safe-signs;  IvBSA's  editing  commands  provide  some  help 
in  entering  the  definitions  into  the  specification,  but  cannot  provide  any  suggestions  as 
i -  what  the  definitions  should  be. 
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The  effort  of  developing  a  domain  model  can  be  lessened  by  reusing  d  <: 
Our  experience  so  far  has  shown  that  some  components  of  domain  mod 
reusable.  For  example,  we  find  that  basic  terms  such  as  physical  objects. 
p»opim  etc.,  are  used  over  and  over  again.  We  have  built  a  library  of  sue. 
and  have  provided  mechanisms  for  including  these  into  a  specification. 


Unfortunately,  simply  building  a  library  of  components  is  not  the  answ •  • 
given  domain  model,  each  object  will  be  associated  with  a  number 
relationships,  constraints,  and  behaviors.  The  specifier  needs  control  c\n  - 
these  relationships  and  behaviors  are  included  in  the  specification.  Other 

complexity  of  the  model  will  be  too  great,  and  the  specifier  will  hav< 
understanding  the  specification  and  making  sure  that  it  is  correct.  What  is  r 
other  words,  is  a  way  of  constructing  a  view  of  an  existing  domain  model  for 
into  a  new  specification. 


The  patient-monitoring  application  illustrates  w'ith  the  problems  associated  wit  a 
making  use  of  an  existing  domain  model  unaltered.  Suppose  that  we  started  with  a 
standard  mode)  of  a  hospital.  Such  a  model  would  include  information  about  when 
patients  are  admitted  and  discharged,  how  monitoring  devices  in  cardiac  wards  differ 
from  those  in  orthopedic  wards,  etc.  Such  a  modei  would  introduce  a  number  of 
exceptions  and  special  cases  into  the  specification  right  at  the  beginning.  If  a  specifier 
attempts  to  address  all  of  these  aspects  of  the  domain  model  at  once,  mistakes  are  likely 
to  arise.  It  is  crucially  important  that  the  domain  model  be  idealized  in  the  initial 
stages  of  specification  development,  so  that  the  initial  specification  of  requirements  can 
also  be  kept  simple  and  easy  to  validate.  The  details  of  the  domain  model  should  then 
be  introduced  in  a  gradual  manner,  and  their  implications  propagated  through  the 
specification. 


At  the  present  time  IvBSA  supports  a  simplified  mechanism  for  incorporating  views  of 
''timr  specifications,  and  of  domain  models  in  particular,  into  a  specification.  The  user 
ean  indicate  which  terms  are  to  be  included  in  a  specification.  The  definitions  of  those 
terms  are  then  imported  into  the  specification. 


’  *  *  ^  t  ^  *  *  *  '  ^  "  »  "  «  -  v  •  w  w  « 
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The  pror.le:n  of  how  ;•  : re  s]  >eo  i 10:  is  in  general  quite  hari. 

.Wvi-rt i.r-iess,  w *•  •  -w arcs  tackling  the  problem.  Wc  have 

inip.'  ii.ent.  !  a  mechanism  m  •  if  >■  Ada  packrg'-s  for  inclusion  of  views  into  a 
v.x-  •ifiva'i.'i..  A  •;  ■  -dot  r  ran  .-<dVr  o- ;  t.  existing  specification,  select  definitions  from 
that  -  i :"i <  >!..  rename  ti.ei.,  n*-c--.s  try,  and  include  them  in  the  specificati  >n  that 

in  is  vo  -rking  on.  '.'sing  this  feature,  w-  have  started  building  a  library  of  reusable  Gist 
h-fiaiii.  wh. .  n  ran  be  ineinoed  :n  .  .  ariety  o;  specifications. 

fne  package  tes.hr. cm-  w-rks  fine  if  u-  views  ha\ e  disjoint  sets  of  definitions;  the 
situate  m  becomes  more  complex  when  u.e  views  each  define  the  same  ternts.  The  most 
coin  in  on  nation  where  this  arises  is  where  behavior  is  described  as  being  random  or 
u:.con«t rained  in  clew,  and  deterministic  in  another  view.  Such  is  the  case  when  a 

view  desi  v  ■  •  *he  properties  of  one  agent,  but  only  minimally  describes  the  properties 
of  externa!  agents.  A  view  describing  what  the  radar  system  does  might  describe 
aircraft  as  being  in  random  positions.  In  this  view,  the  radar  system  informs  the  air- 
*  raffic  control  system  of  the  aircraft  positions  regardless  of  where  the  aircraft  are.  Since 
the  aircraft  positions  are  unconstrained  in  the  radar  view,  the  view  can  readily  be 
combined  with,  a  view  in  which  the  aircraft  positions  are  constrained  to  follow  some 
flight  path.  We  are  currently  developing  analysis  tools  in  KBSA  for  detecting  when 
unconstrained  descriptions  and  deterministic  descriptions  can  safely  be  merged. 

The  next  step  in  this  work  is  to  provide  better  control  over  how  a  view  is  constructed. 
One  typically  wants  to  add  or  remove  constraints  from  a  model,  and  there  are  choices 
to  be  made  as  to  which  constraints  should  be  added  or  removed.  Sometimes 

const raitied  behavior  is  changed  to  random  behavior.  In  the  patient-monitoring 
example,  device  readings  are  a  function  of  patient  vital  signs.  If  we  were  to  remove 
patient  vital  signs  from  the  model,  then  the  device  readings  would  appear  to  change 
randomly.  On  the  other  hand,  sometimes  new  constraints  must  be  added  when 

abstracting  a  view.  The  general  hospital  model  might  describe  how  patients  are 

admitted  and  discharged;  however,  when  constructing  an  ideal  view  it  may  be  useful  at 
first  to  ignore  admission  and  discharging  and  assume  that  the  set  of  patients  is  fixed. 
H'gh-leve!  editing  commands  will  be  useful  for  performing  the  abstraction  steps. 


61 


3.3.  Providing  More  Intelligent  Assistance 

High-level  editing  commands  and  view  extraction  are  useful  technique*  for  >  t .  rting 
specification  development.  However,  decisions  still  have  to  be  made  as  to  w.nich 
command  is  the  right  one  to  apply.  It  has  become  clear  that  KBS  A  can  perform  a  m<  -re 
active  role  in  deciding  which  commands  are  appropriate.  IvBSA  could  assist  the  user  in 
deciding  which  commands  should  be  applied  to  fix  a  particular  flaw  In  'he  specification. 
In  addition,  it  could  track  the  development  process,  to  make  sure  that  the  user's 
intended  requirements  are  properly  met  in  the  final  specification.  Each  of  these  issues 
are  discussed  m  [14]. 

We  presume  that  the  specifier  frequently  refines  the  specification  pv  looking  at  it, 
identifying  things  that  are  incorrect  or  missing,  decides  how  they  ought  io  be  changed, 
and  then  effects  the  change.  We  call  aspects  of  the  specification  that  are  incorrect  or 
missing  issues ,  and  intended  changes  development  goals.  By  providing  knowledge  into 
IvBSA  of  what  kinds  of  issues  to  look  for,  and  how  issues,  goals,  and  editing  commands 
relate  to  each  other,  IvBSA  can  provide  guidance  as  to  how  the  specification  can  be 
modified,  and  perhaps  make  the  changes  itself,  with  user  approval. 

In  the  larger  scale,  KBSA  will  have  the  capability  of  recording  and  tracking  the 
overall  specification  development.  This  involves  recording  what  high-level  editing 
commands  were  applied,  and  what  goals  they  were  intended  to  achieve,  if  known  by 
KBSA.  .-Vs  the  process  proceeds,  IvBSA  can  monitor  the  development  process  and  check 
that  high-level  requirements  are  not  unintentionally  violated  as  the  development 
pro  . . is. 

4.  Evaluation  Tools 

KBSA  contains  a  number  of  different  kinds  of  evaluation  tools,  including  the 

f '!!'  a  ing: 

•  a  symbolic  evaluator, 

•  a  concrete  simulator, 

•  a  number  of  static  analysis  tools,  including  type  analysis  and  resource 


analysis. 

Each  w  ; i  1  he  lie-'cri bed  below. 

4.1.  The  Symbolic  Exaluator 

IvBSA's  symbolic  evaluator  is  an  extension  of  KOKO,  the  symbolic  evaluator 
developed  earlier  at  ISJ  [l.  5,  6j.  KOKO  was  converted  from  INTERLISP  with  AP3  [12] 
to  Common  LISP  with  FSD/AP5  [2,  7j.  It  was  adapted  to  handle  NBSA's  new  internal 
representation  of  Gist,  reflectin';  some  new  constructs  that  have  been  added,  and 
changes  to  the  semantics.  It  was  also  modified  to  allow  the  user  to  switch  easily 
between  different  specifications  that  are  being  developed  simultaneously. 


We  intend  to  make  several  nontrivial  extensions  to  KOKO  in  order  to  cover  more  of 
Gist.  For  example,  temporal  reference  and  parallel  execution  are  not  currently  handled. 
Parallel  execution  in  particular  will  involve  a  significant  amount  of  effort.  For  one 
thing.  KOKO  currently  has  no  way  of  representing  nondeterministic  interleaving  of 
events.  It  cannot  represent,  for  example,  that  three  events  (patient  becomes  unsafe, 
patient  becomes  safe,  and  nurse  is  notified)  occur  in  a  specified  order  but  with  arbitrary 
behavior  interleaved.  We  hope  that  this  can  be  effectively  accomplished  by  allowing 
concrete  sequences  of  states  to  be  followed  or  preceded  (and  thus  connected)  by 
indefinite  behaviors,  which  are  described  by  sets  of  temporal  axioms  (similar  to  the 
axioms  in  definite  states  except  that  time  is  an  explicit  parameter). 


The  major  new  application  of  the  symbolic  evaluator  that  we  envision  is  in  the 


a! nation  cf  scenarios. 


That  is,  the  user  may  present  a  prototypical  sequence  of 


imti-'iis,  and  use  the  symbolic  evaluator  to  determine  whether  or  not  the  scenario  is  a 
b-ga!  behavior,  and  under  what  conditions  it  will  be  executed.  Since  people  often 


validate  s; 


bfkations  by  working  through  prototypical  scenarios,  such  a  feature  would 


be  a  significant  aid  for  checking  specifications. 


-- vW/yv. 
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4.2.  The  Concrete  Simulator 

To  complement  the  capabilities  of  the  symbolic  evaluator  we  h.i 
concrete  simulator  for  Gist.  The  simulator  takes  concrete  example  1  .  *»r.  '  •  •:: 

them  through  the  specification.  Since  it  cannot  be  used  to  execute  symbeuc  d.va.  i’ 
impossible  to  prove  general  statements  about  a  specification's  behavior  rc:iu  ' 
concrete  simulator.  On  the  other  hand,  the  simulator  can  trace  much  wore  com  pm': 
executions  than  the  symbolic  evaluator  can.  It  can  execute  all  of  the  •constructs  A  G.st, 
including  a  number  of  constructs  that  the  symbolic  evaluator  cannot-  handle.  It  •car. 
execute  a  number  of  processes  in  parallel;  the  symbolic  t valuator,  in  contrast,  only 
follows  a  single  line  of  control  at  a  time. 

4.3.  Static  Analysis  Tools 

A  number  of  tools  have  been  implemented,  or  are  being  developed,  which  perform 
static  analyses  of  specifications.  One  set  of  tools,  the  type  checking  tools,  employ 
standard  techniques  for  checking  the  declared  types  of  objects,  types  of  parameters,  etc. 
This  form  of  static  analysis  is  a  prerequisite  for  a  number  of  the  tools  in  KBS  A. 
including  both  the  symbolic  evaluator  and  the  concrete  simulator. 

Further  analysis  tools  will  provide  feedback  on  how  the  specification  is  constructed, 
and  whether  or  not  it  appears  complete.  One  tool  under  development  examines  data 
accesses  in  the  specification,  and  in  particular  which  accesses  cross  over  data  boundaries. 
If  the  specifier  describes  what  kind  of  data  accesses  are  expected,  the  system  will  be  able 
to  indicate  whether  or  not  the  specification  meets  expectations. 

5.  Explanation 

Another  major  aid  to  specification  understanding  is  be  the  IvBSA  explanation  facility. 
This  facility  helps  users  better  understand  their  specifications  by  producing  natural 
language  (English)  paraphrases  of  the  specifications,  explanations  of  the  behaviors  they 
denote,  descriptions  of  how  the  specifications  were  developed,  and  the  rationale  behind 
that  development,  it  extends  the  capabilities  of  the  Gist  Paraphrase!  [18)  which  was 
developed  under  a  previous  contract  [l].  In  the  remainder  of  this  section,  we  first 
discuss  the  re-implementation  of  the  Gist  Paraphraser  and  then  discuss  our  plans  for 


future  enhancements  te  the  exp!. mat  ion  capabilities  of  the  system. 

5.1.  The  Gist  Paraphrase!-:  Current  Status 

The  Gist  Paraphraser  produces  natural  language  paraphrases  of  Gist  specifications. 
We  originally  developed  this  tool  to  make  Gist  more  accessable  to  people  who  were  not 
familiar  with  Gist.  While  the  Paraphraser  was  useful  in  this  capacity,  we  were 
surprised  to  discover  that  it  served  another  (and  perhaps  more  important)  role  as  a 
debugging  aid.  We  found  that  a  natural  language  paraphrase  of  a  specification  often 
made  bugs  in  the  specification  very  apparent  that  were  hidden  in  the  formal 
specification.  Partially,  this  was  due  to  the  fact  that  natural  language  is  inherently 
more  understandable,  but  it  is  also  due  to  the  fact  that  the  paraphrase  provided  the 
user  with  another  view  of  his  specification  that  stressed  certain  aspects  of  the 
specification  that  ware  not  emphasized  in  the  formal  notation. 

We  have  re-implemented  the  old  Paraphraser  in  the  new  KBSA  environment.  .As  with 
the  symbolic  evaluator,  this  involved  converting  it  from  Interlisp  with  AP3  to  Common 
Lisp  with  FSD/AP5  and  dealing  with  the  new  Gist  syntax.  There  have  been  several 
changes  to  the  paraphraser  itself.  The  major  change  has  been  to  move  from  a  case 
grammar  based  generator  to  a  functional  (or  unification)  grammar  based  generator. 
The  major  advantage  of  this  approach  is  that  it  will  make  the  generator  much  more 
flexible,  which  will  help  us  in  developing  the  more  sophisticated  explanation  capabilities 

o 

we  describe  below. 

To  correctly  paraphrase  a  specification,  the  new  Paraphraser  (like  the  old  one)  needs  a 
few  a:..;-: aliens  to  augment  the  specification  that  tell  in  how  certain  kinds  of  constructs 
'such  as  action  invocations)  should  be  translated.  In  the  old  paraphraser.  this 
information  had  to  be  hand-coded.  One  of  the  enhancements  of  the  new  paraphraser  is 
that  it  'an  interactively  acquire  the  annotations  from  the  user.  Whenever  the  user  has 
nached  a  point  in  the  development  where  paraphrasing  could  be  useful,  the  necessary 


"A  typical  problem  with  unification  generators  has  been  their  efficiency.  By  carefully  optimizing  the 
rode  we  originally  obtained  from  Columbia  University,  we  have  been  able  to  speed  the  generator  up 
approximately  two  orders  of  magnitude  so  that  efficiency  is  not  a  problem. 
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annotations  can  be  added  at  that  point.  It  can  also  function  without  the  annotaii;  ns. 
at  the  cost  of  a  somewhat  less  natural-sounding  paraphrase. 

5.2.  Current  Work 

We  are  currently  developing  a  generalized  framework  for  explanation  This 
framework,  called  the  Specification  Explainer,  will  be  used  both  by  tlm  KBSA  project 
and  by  the  Explainable  Expert  Systems  project  [16].  The  shared  framework  is 
appropriate  because  KBSA  and  EES  are  both  used  to  develop  software  systems  in  ar; 
explainable  fashion.  EES  focuses  on  the  development  of  expert  systems,  whereas  KBSA 
is  applicable  to  general  software.  Nevertheless,  many  of  the  same  issues  apply,  such  as 
explaining  how  a  particular  term  is  used  in  the  system,  or  describing  how  a  given 
requirement  is  achieved  in  the  implemented  system. 

The  Specification  Explainer  will  have  the  ability  to  plan  explanations.  The 
explanation  planner  will  employ  a  set  of  explanation  strategies  in  constructing  its 
explanations.  Based  on  what  the  user  needs  to  know  (as  indicated,  for  example,  by  the 
queries  he  poses)  the  system  will  plan  an  explanation  to  convey  the  needed  information 
to  him.  The  planner  will  take  into  account  the  user's  expertise  and  prior  knowledge  to 
select  appropriate  ways  of  conveying  information  to  the  user. 

The  Specification  Explainer  will  allow  the  user  to  ask  follow-on  questions  if  he  doesn’t 
understand  the  explanations  it  offers.  To  produce  the  follow-on  explanations,  the 
system  will  examine  the  plan  used  to  produce  the  explanation  that  was  not  understood, 
and  "debug"  it  by  selecting  an  alternate  strategy  for  conveying  the  information  that 
was  not  understood  in  the  original  explanation. 

The  Specification  Explainer  will  also  benefit  substantially  from  being  able  to  employ 
the  incremental  development  history  to  offer  explanations  that  reflect  the  system  at 
various  stages  of  development  and  levels  of  abstraction.  The  Explainer  will  also  be  able 
to  explain  the  rationale  behind  changes  made  to  the  specification  and  specification 
»  that  are  introduced  because  the  incremental  development,  history  will  record 
’hat  information. 


6.  Current  Status  and  Prospectus 

In  recapitulation,  the  following  is  a  summary  of  the  steps  that  have  been  taken  so  far 
in  constructing  KBSA: 

•  the  basic  editing  environment  for  KBSA  has  been  built; 

•  a  library  of  high-level  editing  commands  have  been  constructed; 

•  prototype  view  construction  facilities  have  been  developed; 

•  mechanisms  for  describing  data  boundaries  within  specifications  have  been 
developed; 

•  the  Gist  Symbolic  Evaluator  has  been  included  into  KBSA; 

•  a  concrete  simulator  has  been  developed; 

•  static  type  and  resource  analyzers  have  been  constructed; 

•  the  Gist  Paraphraser  has  been  rewritten  and  extended. 

The  following  are  key  issues  which  we  must  address  in  the  future  in  our 
implementation. 

•  KBSA  should  provide  more  assistance  in  selecting  high-level  editing 
commands.  This  requires  representing  more  knowledge  about  what 
development  goals  high-level  editing  commands  can  achieve,  as  well  as  more 
of  the  user's  expectations  about  the  specification, 

•  The  explanation  component  of  KBSA  has  not  been  implementable  up  to 
now,  because  we  did  not  have  examples  of  specification  developments  to  use 
for  explanation.  Now  that  we  have  those  examples,  we  can  start  work  in 
earnest  of  explanation  in  KBSA. 

When  these  steps  are  accomplished,  and  as  the  existing  KBSA  components  are  extended, 
we  expect  to  see  KBSA  make  significant  progress  toward  being  a  helpful,  cooperative, 
and  intelligent  aid  to  specification  development. 
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I.  A  Brief  Description  of  Gist  Syntax 

This  i>  a  brief  overview  of  Gist  1987.  the  latest  version  of  the  Gist  .sperifcathui 
language.  It  describes  the  grammar  and  semantics  of  the  language,  focusing  on  the 
differences  between  this  grammar  and  the  one  described  in  the  1980  Gist  Manual  ’ll;. 
Some  details  of  Gist  have  been  skipped  here;  readers  seeking  more  information  should 
consult  the  Gist  Manual. 


The  grammatical  notation  used  in  this  text  is  an  extended  version  of  BN'F. 

•  Keywords  in  the  Gist  language  are  in  typewriter  font.  Non-terminal 
names  and  BNT  notation  are  in  italics.  All  non-terminal  names  are 
bracketed  by 

•  Optional  constituents  are  enclosed  in  braces:  {...}. 

•  Alternative  constituents  are  separated  by  the  symbol  |. 

•  Constituents  may  be  grouped  together  using  parentheses  to  indicate  the 
scope  of  the  symbol  |:  (...). 

•  The  symbol  *  following  a  constituent  indicates  that  zero  or  more  instances  of 
that  constituent  may  occur.  The  symbol  +  indicates  that  one  or  more 
instances  may  occur. 


Gist  specifications  consist  of  a  set  of  declarations.  The  following  kinds  of  things  are 
declared  within  Gist  specifications: 

•  types, 

•  relations, 

•  demons, 


•  functions. 


•  invariants,  and 

•  procedures. 


The  relationship  between  declarations  in  Gist  1987  and  declarations  in  previous 
versions  of  Gist  are  as  follows.  Types  subsume  both  types  and  agents  in  the  older 
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versions  of  Gist.  Relations  and  demons  are  just  as  before.  Procedures  are  what  used  to 
be  called  "actions";  invariants  are  what  used  to  be  called  "constraints".  1  unctions,  a 
new  kind  of  declaration,  provide  a  way  of  defining  applicative  expressions  whirl)  at- 
repeatedly  referred  to  in  a  specification. 

1.1.  Changes  to  Expressions  and  Predicates 

We  will  not  go  into  the  details  of  the  various  Gist  statements,  expressions,  and 
predicates  here.  The  meaning  of  most  of  them  are  the  same  as  what  was  available  in 
earlier  versions  of  Gist.  The  reader  should  be  aware  of  the  following  changes  in  the 
syntax  of  expressions  and  predicates,  however. 

•  A  relation  with  a  question  mark  (?)  in  it  is  used  to  refer  to  an  object  that 
satisfies  the  relation.  Thus,  for  example, 

asslgned-ward Cnursel ,  ?) 

refers  to  the  object  x  such  that  the  asslgned-ward  relation  holds  between 
nursel  and  x. 

•  A  double  bar  (II)  in  a  quantified  predicate  is  used  to  separate  the  list  of 
quantified  variables  from  the  predicate  that  is  quantified.  For  example,  "all 
men  are  mortal"  would  be  rendered  in  Gist  as 

•  for  all  man  I  I  mortal (man) 

•  The  attribute  notation  of  Gist,  of  the  form  < object  >  :  < attribute > ,  has 
been  generalized.  The  constituent  following  the  :  can  now  be  a  a  predicate, 
function  call,  or  procedure  invocation.  When  this  is  done,  the  first 
parameter  to  the  relation,  function,  or  procedure  is  elided,  as  is  the  case 
when  declarations  are  embedded  (see  Section  1.2.1)  below.  For  example,  the 
following  three  expressions  are  the  same: 

nursel : asslgned-ward 
asslgned-ward (nursel ,  ?) 
nursel : asslgned-ward (?) 

•  The  syntax  of  temporal  expressions  has  changed.  Temporal  predicates  and 
expressions  have  the  following  form: 

i  < predicate >  |  <expression> )  as  of  <time-expression  > , 

w  here  <t.lme-expresslon>  can  be  one  of  the  following: 


when  <predicate  > 


/first  |  last  |  any  |  all  )  (prior  |  subsequent  )  time 

{  |  |  <predicate>  } 

1.2.  Type  Declarations 

Type  declarations  take  the  form 

<qualifier>*  type  <name>  < type-relators > 

{  with  {  < declarations >+  >  } 

The  meanings  of  these  fields  will  be  described  with  reference  to  the  following  example 

type  definition: 

static  type  nurse 

subtype  of  person  with  < 

relation  asslgned-ward (ward) 

> 

The  qualifiers  are  shorthand  for  various  common  invariants  that  apply  to  types,  and 
demons  that  create  and  destroy  types.  They  can  include  ar.v  of  the  following: 

•  dynamic  (default)  or  static, 

•  singleton,  non-empty,  singleton  or  empty,  or  non-empty  or 

empty  (default), 

•  explicit  (default)  or  Implicit 

dynamic  indicates  that  instances  of  the  type  may  be  created  and  destroyed  during  the 
course  of  a  behavior,  static  indicates  that  creation  and  destruction  are  disallowed; 
the  same  set  of  instances  of  the  type  must  exist  throughout  all  behaviors,  nurse  in  the 
above  example  is  an  instance  of  a  static  type;  the  specification  presumes  that  the 
number  of  nurses  is  fixed. 

If  a  type  is  marked  singleton,  only  one  instance  of  the  type  may  exist  at  any  one 
time,  non-empty  types  must  have  at  least  one  instance  at  any  given  time.  Note  that 
there  is  no  guarantee  that  the  same  instance  or  instances  exist  at  all  times:  such  a 
guarantee  obtains  only  with  static  types. 

Instances  of  explicit  types  must  be  explicitly  created  and  destroyed  via  create 


statements  and  destroy  statements,  implicit  types,  on  the  other  hand,  are  never 
explicitly  created  or  destroyed.  Instead,  declaring  a  type  implicit  is  equivalent 
semantically  to  defining  a  demon  that  nondeterministically  creates  and  destroys  objects 
of  the  type,  and  that  is  the  sole  demon  capable  of  creating  and  destroying  these  objects, 
implicit  types  are  typically  used  to  define  derived  types,  i.e..  where  membership  of 
the  type  is  implied  by  some  predicate.  For  example,  the  following  definition  delines  the 
type  patient  as  a  derived  type:  a  person  is  a  patient  if  and  only  if  the  person  has  been 

admitted  to  a  hospital. 

•implicit  type  patient  with  < 

invariant  (self  lsa  patient)  <=> 

((self  lsa  person)  and  (admitted (self )) ) 

> 

The  type  relators  indicate  how  the  type  relates  to  other  types  in  the  type  hierarchy. 
A  type  can  be  declared  a  subtype  of  another  type,  a  supertype  of  another  type,  or  can 
be  declared  equivalent  to  another  type.  Gist  now  allows  sets  and  sequences  of  objects  to 
be  treated  as  types;  type  relators  are  used  to  indicate  what  type  the  members  of  the  sets 
or  sequences  should  belong  to. 

1.2.1.  Embedded  declarations 

Declarations  can  be  embedded  within  a  type  declaration.  This  embedding  is  a 
notational  convenience;  it  does  not  affect  the  semantics  of  the  definition.  When  a 
declaration  is  embedded  within  a  type  it  can  make  use  of  the  symbol  self  to  refer  to 
an  instance  of  the  type,  as  in  the  definition  of  patient  shown  above.  If  a  relation, 
procedure,  or  demon  is  declared  within  a  type,  self  serves  implicitly  as  the  first 
parameter  to  the  embedded  declaration. 

The  definitions  of  nurse  and  patient  shown  above  are  shown  in  Figure  1-1,  followed 
by  equivalent  definitions  without  embedding.  These  examples  should  make  clear  how 
embedded  and  non-embedded  declarations  relate  to  each  other. 


Embedded  forms: 
static  type  nurse 

subtype  of  person  with  { 

relation  asslgned-ward (ward) 

> 

Implicit  type  patient  with  { 

Invariant  (self  Isa  patient)  <=> 

((self  Isa  person)  and  (admitted (self )) ) 

> 


Unembedded  forms: 

static  type  nurse 
subtype  of  person; 

relation  asslgned-ward (nurse ,  ward); 

Implicit  type  patient; 

Invariant  for  all  pi  entity  II 

(p  Isa  patient)  <=>  ((p  Isa  person)  and  (admitted  (p) ) ) 

Figure  1-1:  Comparison  of  Embedded  and  Unembedded  Declarations 

1.3.  Relation  Declarations 

Relation  declarations  have  the  form 

<quali fier>  *  relation  <name>  (  {  <parametcre>  }  ) 

{  (  Iff  |  requires  )  <predicate>  } 

The  following  is  an  example  of  a  relation  declaration:  it  states  that  the  relation 
unsafe-signs  is  true  of  a  patient  if  and  only  if  safe-signs  is  not  true  of  the 

patient. 

Implicit  relation  unsafe-signs (p Ipatlent)  Iff 
—  safe-signs  (p) 

Qualifiers  here  have  similar  meanings  to  those  in  type  definitions.  The  implicit 
qualifier  in  the  case  of  relations  is  shorthand  for  a  demon  that  nondeterministically 
inserts  and  removes  tuples  of  that  relation.  Parameters,  if  present,  are  in  one  of  the 
following  forms: 


•  <  type-name  > 


•  <ncmt>  I  <type-name> 

In  either  case,  the  parameter  is  constrained  to  be  of  type  type-name.. 

If  the  iff  or  requires  field  is  defined,  it  defines  constraints  on  when  tin-  relation 
may  hold,  iff  signifies  the  relation  holds  if  and  only  if  the  predicate  that  follow -•  is 
true:  requires  signifies  that  the  relation  may  hold  only  if  the  predicate  is  true,  hut 
does  not  necessarily  hold.  The  predicate  may  refer  to  parameters  as  bound  variables; 
the  parameter  p  is  referred  to  in  this  manner  in  the  definition  of  unsafe-signs  shown 
above. 

1.4.  Demon  Declarations 

A  demon  is  an  activity  which  is  initiated  when  some  predicate  becomes  true.  Ram 

■•'t:\hy  is  performed  in  parallel  with  other  activities  in  the  system,  ;v  a  separate  l:r.«  of 

■  1.  Demon  declarations  have  the  following  form: 

|  serial  I  parallel  }  demon  <name>  [  {  <r  parameters  >  }  ] 

;  let  <bindings >  In  } 

when  <predicate >  do  <statement > 

An  example  of  a  demon  is  the  following: 

demon  notify-nurse  [patient] 
when  safe-signs  (patient) 
do  insert  lenows-unsafe  (nurse  ,  patient) 

T:.v  parameter  list  is  used  to  control  how  many  instantiations  of  the  demon  may  be 
:i'"tiv-  at  any  one  time.  Without  parameters,  the  demon  is  activated  exactly  once  when 
the  predicate  becomes  true.  With  parameters,  the  demon  is  activated  for  every  distinct 
binding  of  the  parameters  that  make  the  demon  become  true.  As  an  example,  consider 
the  notify-nurse  demon  shown  above,  patient  is  a  parameter  to  the  demon:  that 
meat.'  that  a  separate  demon  instantiation  arises  for  each  patient  such  that 
--  saf  e-signs  (patient) 

:  ■  :;.ec  true.  If  two  patients  become  unsafe  at  the  same  time,  there  will  be  two  demon 

!:  n:, Rations  simultaneously. 

•i 


Demons  may  take  time  to  execute.  What  happens  if  the  triggering  predicate  of  the 
demon  becomes  true  while  the  demon  is  still  active?  The  answer  depends  upon  whether 
or  not  the  qualifiers  serial  or  parallel  are  included.  If  parallel,  a  new  demon 
instantiation  is  created,  which  executes  in  parallel  with  the  previous  one.  If  serial, 
the  demon  cannot  be  re-invoked  on  the  same  parameters  until  the  previous  instantiation 
of  the  demon  is  terminated  (invocations  on  different  parameters  are  allowed,  however). 
If  neither  serial  nor  parallel  is  indicated,  parallel  is  assumed. 

1.5.  Function  Declarations 

Function  declarations  are  a  convenient  way  of  defining  expressions  which  are  used 

repeatedly  in  a  specification.  Functions  take  the  form 

function  <narne>  (  {  <parameters>  }  ) 

{  returns  <type>  } 
definition  <expression> 

The  expression  in  the  body  of  the  function  is  assumed  to  be  applicative.  Functions  are 
always  evaluated  instantaneously;  there  can  be  no  state  transition  within  a  function 
execution. 


Note  that  functions  bear  a  similarity  to  implicit  relations.  For  example,  the  following 
function  definition  and  relation  definition  both  define  factorials. 

function  factorial (n I  natural-number) 
definition 
If  n  =  0 
then  1 

else  n  *  (factorlal(n  -  1)) 

Implicit  relation  factorial (nl I  natural-number,  n2 I  natural-number) 
Iff  ((nl  =  0)  and  (n2  =  1)) 

or  (factorial (nl ,  n  *  (factorlal(n  -  1)))) 


1.6.  Invariants 

Invariants  lake  the  following  form: 
Invariant  < predicate > 


Thi'  predicat*  in  an  invariant  must  be  true  in  every  state  of  every  behavior. 


The  interpretation  of  an  invariant  depends  upon  whether  the  types  nd  re'.ition=  in 
the  predicate  are  dynamic  or  static,  and  whether  they  are  implicit  or  exom::.  M  any  <>'. 
the  types  and  relations  are  dynamic  and  explicit,  then  the  specification  must  d- f in¬ 
activities  that  make  the  predicate  true;  otherwise  the  behavior  is  disallowed,  li  nl.  «.■: 
the  types  and  relations  are  static  or  implicit,  then  stating,  the  invariant  is  sufiVlct.  t  ■ 
guarantee  that  the  invariant  holds,  assuming  that  it  is  not  inconsistent  with  t  he  r«>; 
the  si  -ecification.  No  additional  behavior  definition  is  required. 

An  example  will  make  the  distinction  clear.  Suppose  tftat  v "  have  the  foil/ whig 
invariant  appears  in  a  specification: 

invariant  for  all  nlnurse  II 

exists  wlward  II  asslgned-to (n ,  w) 

This  invariant  states  that  for  every  nurse  there  exists  a  ward  that  that  nurse  is 
assicn-d  to.  Suppose  that  nurse,  ward,  and  asslgned-to  arc  all  dynamic  am! 
exp  11  -it.  This  means  that  nurse  and  ward  objects  exist  in  a  behavior  only  if  some 
activity  creates  them;  asslgned-to  is  true  only  if  explicitly  asserted.  Any  behaviors  in 
will:-:,  nurses  are  created  but  no  corresponding  asslgned-to  assertion  exists  arc 
treated  as  anomalous;  they  are  excluded  from  the  set  of  valid  behaviors.  Now  suppose 
that  the  nurse,  ward,  and  asslgned-to  are  all  static.  Then  no  behavior  cat)  create 
the  types,  or  assert  the  relation.  Instead,  a  different  initial  behavior  state  is  presumed 
to  exist  for  each  configuration  of  nurses,  wards,  and  ward  assignments  that  satisfies  the 
ir.v  ariants. 

If  dynamic  and  static  relations  are  mixed  in  an  invariant,  the  invariant  may  or  may 
r.  ‘  :  ■■  statically  guaranteeable;  it  depends  upon  the  invariant.  In  order  t.  •  kre;  ’lie 
iiit-r:  o  'ation  clear,  we  try  to  avoid  mixing  dynamic  and  static  relations  in  invariants. 

1.7.  Procedures 

Pr  lure?  are  what  used  to  be  called  "actions"  in  earlier  versions  f  ( fist .  T !.*•;,  v.  • 

*  :/•  f  T  -wing  form: 

procedure  <nnme  >  [  {  <paravicters  >  }  ] 

returns  <  types  >  } 


definition  <statement> 

Procedures  are  used  to  define  activities  and  events.  They  are  executed  only  when 
explicitly  invoked.  Procedure  definitions  consists  of  primitive  database  operations  that 
create  or  destroy  objects,  or  which  delete,  insert,  or  update  relations.  These  contrast 
with  functions,  which  cannot  modify  relations  or  objects.  Procedures  can  optionally 
return  one  or  more  values. 
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1  Goals  of  a  Performance  Estimator  Assistant 

As  defined  in  [2],  the  long-term  goal  of  a  Performance  Estimator  Assistant  (PEA)  is  to  aid 
in  the  creation  and  maintenance  of  programs  that  meet  their  performance  requirements  or, 
if  specific  performance  requirements  have  not  been  stated,  are  generally  efficient  in  their  use 
of  computational  resources.  The  principal  function  of  the  Performance  Estimation  Assistant 
is  to  guide  implementation  decisions  that  will  affect  the  ultimate  performance  of  the  system, 
by  generating  and  reasoning  about  performance  estimates  for  expressions  ranging  from  very- 
high-level  specifications  to  low-level  code.  For  example,  efficiency  estimates  can  be  used  to 
choose  between  alternative  low-level  implementations  of  high-level,  set-theoretic  data  struc¬ 
tures  [4].  Efficiency  estimates  aiso  provide  the  basis  for  choosing  amoDg  alternative  control 
structures,  optimization  transforms,  library  routines,  and  so  on.  Performance  estimation 
over  a  rich  space  of  alternative  implementations  is  the  feature  that  differentiates  a  practical 
program  synthesizer  from  an  executable  specification  language  good  only  for  prototyping. 

The  short-term  goals  for  PEA  capabilities  called  out  in  [2]  are: 

•  symbolic  evaluation  [3]  [1], 

•  data  structure  analysis  and  advice  [4],  and 

•  subroutine  and  module  decomposition  advice. 

’This  research  was  supported  by  the  Rome  Air  Development  Center  (RADC)  under  contract  F30602- 
86-C-0026  The  views  and  conclusions  contained  in  this  paper  are  those  of  the  authors  and  should  no(  be 
interpreted  as  representing  the  official  policies,  either  expressed  or  implied  of  RADC  or  the  U  S  Government 
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Figure  1:  Current  Paradigm 

Mid-term  goals  are: 

•  domain  models  for  analysis, 

•  algorithm  design  analysis  and  advice,  and 

•  real-time  performance  advice. 

2  Performance  Analysis  and  Paradigms  for  Software 
Engineering 

In  the  conventional  paradigm  of  software  engineering,  depicted  in  Figure  1,  code  is  developed 
in  an  intuitive  and  largely  informal  manner  from  requirements  and  specifications.  The  result¬ 
ing  code  is  typically  incorrect  and  has  unknown  performance  characteristics.  To  ascertain 
the  correctness  of  the  code  we  test  it  with  examples  or  verify  it  against  a  formal  specification. 
The  latter  has  the  advantage  of  mathematical  rigor  and  greater  certainty  in  the  correctness 
of  the  code,  although  all  that  we  have  done  is  show  consistency  between  the  specification 
(which  may  be  incorrect)  and  the  resulting  code,  but  it  is  prohibitively  expensive  to  do  this 
in  most  cases.  Likewise  if  we  are  interested  in  the  performance  of  the  code  then  we  usually 
simply  test  it  and  measure  its  performance.  Sometimes  we  perform  analysis  of  its  properties 
and/or  properties  to  get  an  assessment  of  resource  utilization.  Again  it  is  expensive  to  do 
this  in  many  cases. 

The  transformational  paradigm  (see  Figure  2)  finesses  these  issues  by  developing  code  and 
properties  incrementally  from  specifications  by  a  sequence  of  correctness-preserving  and 
analysis-updating  transformations.  The  resulting  code  and  analysis  is  guaranteed  to  be 
correct  modulo  the  initial  specification  (and  modulo  the  correctness  of  the  transformations 
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Figure  2:  Transformational  Paradigm 

used).  From  the  point  of  view  of  performance  analysis,  another  advantage  to  the  trans¬ 
formational  approach  is  that  performance  information  is  available  to  help  determine  which 
transformations  to  apply  (and  thus  provide  search  guidance). 


Role  of  the  Performance  Estimation  Assistant  in 
the  KBSA 


The  economics  of  computing  forces  performance  to  play  a  centra!  role  in  the  software  life- 
cycle.  We  believe  that  the  PEA  will  provide  valuable  assistance  to  most,  if  not  all,  facets 
of  a  KBSA.  For  example,  the  PEA  can  be  used  by  the  Requirements  Assistant  to  help  as¬ 
sess  the  feasibility  of  the  desired  behavior  with  respect  to  the  available  computational  and 
organizational  resources.  Performance  can  be  used  by  the  Specification  Assistant  to  help 
assess  alternative  modularizations  of  the  target  system.  Performance  can  be  used  by  a  Test- 
and-Integrate  Assistant  to  help  validate  timing  goals  and  constraints  between  modules  and 
overall  system  performance. 

The  most  immediate  and  essential  use  of  the  PEA  will  be  by  the  Development  Assistant. 
While  there  are  many  activities  that  one  would  eventually  want  supported  by  a  PEA,  the 
one  we  are  focussing  most  of  our  attention  on  is  search  guidance  during  development.  The 
development  of  code  from  specifications  can  be  simply  modelled  by  a  tree  structure  where 
nodes  represent  partially  implemented  specifications  and  arcs  represent  transformations  (See 
Figure  3).  Paths  through  the  tree  represent  derivations  where  the  final  nodes  represent  ex¬ 
ecutable  target-language  programs.  Generally  there  are  alternative  transformations  (arcs) 
that  are  applicable  to  any  given  specification  (node)  each  potentially  leading  to  different 
implementations  of  the  initial  specification.  Depending  on  the  granularity  of  our  transfor¬ 
mations,  there  will  typically  be  many  transformations  involved  in  a  derivation  so  the  tree  of 
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alternatives  derivations  can  grow  quite  large,  too  large  in  taxi  to  e>r  3*  ,  .  ; 

A  crucial  role  of  the  PEA  is  help  guide  the  search  through  this  tr-'-  7:  ■  A?: 

that  can  be  derived  are  distinguished  mainly  on  the  the  basis  ot  their  •  •*. .  <1 

they  all  implement  the  same  functionality  (since  transformation  -  axe  /or.-  c.,m  x  . 

Thus  a  PEA  serves  to  help  decide  which  transformations  are  mere  bio ,  ■  ;h»‘-  t 

to  an  acceptably  efficient  program. 

4  Requirements  for  a  Performance  Estimation  Assn? 
tant 

A  system  whose  use  costs  more  than  the  benefit  that  it  produces  ic  civ.  h  a  m<  ■  rjrc 
enterprise.  Concern  for  the  resource  consumption  of  a  software  system  fmb  g.  ner 

rubric  “  performance  estimation  and  analysis.”  The  PEA  can  hr-  hcv  i- 1  -  •  oilection  of 

tools  that  help  to  produce  systems  that  efficiently  use  available  rou  mce 

Uses  of  a  PEA  include: 

1.  Choosing  between  alternatives  during  development  This  was  discussed  above. 

2.  Identifying  bottlenecks.  The  development  facet  needs  *0  identify  portions  of  a  spec¬ 
ification  that  concentrate  resource  utilization  (i.e.  bottlenecks),  since  they  are  oi'-m 
a  profitable  target  of  optimization  transformations.  By  helping  10  identify  such  bot¬ 
tlenecks,  the  PEA  helps  with  the  efficient  scheduling  and  allocation  of  resources  at 
development  time. 

3.  Characterizing  the  resource  utilization  of  a  system.  We  m.-v  ward  v:  explicit  character 
ization  of  the  resource  utilization  of  a  given  specification,  for  co/mm  n  tat  ion  purposes , 
performance  prediction,  explanation,  etc. 

4.  Determining  if  a  system  meets  performance  constraints.  Part  of  the  initial  specific  a  non 
may  be  constraints  on  the  resource  utilization  of  the  target  code  The  PEA  should 
understand  these  constraints  and  be  able  to  reason  about  them  and  propagate  ttieir 
consequences  to  various  parts  of  the  system.  The  PEA  should  help  to  ensure  that  such 
constraints  are  met. 

5.  Analyzing  a  system  for  various  properties  and  relationships.  Underlying  the  ability  to 
measure  resource  utilization  and  to  guide  decision-making  during  development  is  the 
ability  to  detect  and  infer  properties  of  the  system  and  relationships  between  bs  parts. 

6.  Tracking  and  controlling  the  resource  consumption  of  the  development  process  The 
development  process  itself  consumes  resources  and  there  is  a  need  to  monitor  these 
resources,  and,  as  part  of  decision-making,  help  determine  an  effective  allocation  of 
resources  among  various  development  tasks  and  to  help  schedule  them.  There  is  a 
tradeoff  between  the  resources  consumed  during  design  and  the  resource  consumption 


of  the  target  system.  Generally  it  takes  longer  to  find  and  develop  a  more  e:T 
program, 

5  Approaches  to  Performance  Analysis 

We  can  distinguish  four  approaches  of  performance  analysis;  namely,  qualitative  (heuristic, i, 
quantitative  (statistical),  simulation,  and  symbolic.  We  discuss  the  various  characteristics 
of  these  approaches  below  and  how  they  might  be  implemented. 

There  are  several  performance-related  dimensions  that  we  can  use  to  help  characterize  the.se 
approaches. 

•  What  resources  are  of  interest?  Often  we  want  to  minimize  consumption  of  time,  space, 
size  of  particular  data  structures,  processors,  communication,  or  some  combinaiio: 
these. 

•  How  is  the  initial  environment  characterized?  That  is,  if  we  are  interested  in  the  time 
complexity  of  a  program,  then  we  need  to  measure  time  as  a  func’ion  of  some  aspect 
of  the  initial  environment,  particularly  the  input;  e.g.  number  of  bits  to  encode  the 
input,  set  size,  probability  measure,  characteristics  of  a  typical  input. 

•  What  statistic  is  of  interest?  Are  we  interested  in  best  case,  worst  case,  average  rase, 
typical  case  analysis,  amortized  worst-case,  or  some  other? 

•  How  precise  should  the  analysis  be?  It  may  be  that  a  coarse  feature  space  is  sufficient 
for  decision-making  purposes.  In  other  cases  we  may  need  asymptotic,  or  even  more 
precise,  microanalysis  of  the  target  code. 

•  How  accurate  should  the  analysis  be?  It  may  be  that  an  estimate  is  sufficient  for 
decision-making  purposes.  In  other  cases  we  may  need  exact  characterizations  of  re¬ 
source  utilization. 

•  How  general  should  the  analysis  be?  Some  kinds  of  analysis  only  characterize  the 
resource  utilization  of  a  restricted  subset  of  the  problem  domain,  while  others  yield 
more  general  results. 

•  How  expensive  is  the  performance  analysis  task?  There  is  a  tradeoff  between  the  time 
it  takes  to  assess  performance  and  the  precision,  accuracy,  and  generality  of  the  results. 
If  we  need  to  develop  a  program  quickly,  then  a  fast  but  imprecise  approach  ma\  be 
best. 

•  What  program  properties  does  performance  depend  on?  Analysis  of  program  proper¬ 
ties  seems  to  be  a  crucial  capability  underlying  all  of  the  approaches  to  performance 
analysis/estirnation  and  decision-making  during  development. 
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Table  1:  Approaches  to  performance  \r.-’y 

What  kinds  of  information  are  needed  to  supt)>»rl  -hr  abr-ve  dit  .<  don-  of  performance 
estimation0  There  are  at  least  two  kinds.  One  is  nrobh  ni-i:. dependent  kr.oa !<  dge,  e.g.  about 
the  performance  of  various  “primitive"  operators  in  Oie  specification  language.  The  other 
is  problem-specific  and  must  be  supplied  in  the  requirements  and  specification.  Problem- 
specific  information  includes  any  constraints  on  the  desired  performance  of  the  target  system 
and  any  assumptions  that  can  be  made  about  the  environment.  Environmental  assumptions 
could  include  a  probabilistic  measure  of  the  input  domain  or  the  size  of  a  typical  input  or 
the  relative  frequency  with  which  various  operations  are  expected  to  be  performed 

We  now  describe  four  general  approaches  in  terms  of  the  above  dimensions.  Table  1  sum 
marizes  this  discussion. 


•  Qualitative  or  heuristic  performance  analysis  is  based  on  qualities  of  a  specification 
rather  than  quantities.  For  example,  data  structure  implementation  decisions  depend 
on  the  mix’  of  operations  applied  to  the  data  structure.  This  is  a  quahtahn .  m>t 
quantitative  property  of  the  program.  It  may  be  unnecessary  to  determine  the  ew  t 


size  of  the  data  structure,  so  simple  heuristic  reasoning  would  often  suffice  to  guide 
decision-making.  Qualitative  reasoning  is  particularly  appropriate  when  good  perfor¬ 
mance  decisions  can  be  made  on  the  basis  of  relatively  coarse  analysis  of  the  program, 
for  example,  when  the  presence  or  absence  of  certain  features  provides  the  information 
needed  to  choose  generally  efficient  implementations.  The  cost  of  qualitative  analysis 
tends  to  be  low  since  it  does  not  rely  on  general-purpose  inference  or  deep  analysis  By 
its  nature  the  results  of  qualitative  analysis  are  imprecise  and  often  inaccurate — but 
in  certain  domains  that  is  enough  to  lead  quickly  to  good  implementations  most  of  the 
time. 

•  Quantitative  or  statistical  performance  analysis  is  based  on  statistical  properties  of  the 
environment,  the  primitive  operators,  estimates  of  such  quantities  as  data  structure 
sizes  and  selectivity  of  predicates.  Quantitative  analysis  often  involves  typical  case 
analysis  which  has  limited  generality,  but  may  be  indicative  of  general  performance. 
Tim  precision  and  accuracy  of  its  results  vary  dependmg  on  the  precision  and  accu¬ 
racy  of  the  underlying  statistics  and  methods  for  inferring  the  statistics  of  aggregate 
strv.'  ‘-a Typically.  quantitative  analysis  runs  in  time  linear  in  program  size,  so  it  is 
rehu:  <■,%  inexpensive  to  oerforrn 

•  Simulation-based  performance  analysis  is  based  on  statistical  properties  gathered  by 
actually  running  the  specification  on  test  data.  Since  we  only  get  information  about 
the  specifications  behavior  on  a  few  inputs,  this  kind  of  analysis  has  low  generality, 
but  very  precise  and  accurate  measurements  are  possible.  The  cost  of  simulating  can 
be  relatively  high,  depending  on  how  long  it  takes  to  instrument  and  prototype  the 
specification,  and  to  actually  run  it. 

•  Symbolic  performance  analysis  is  potentially  the  most  powerful  approach.  It  is  based  on 
deep  analysis  of  program  properties  and  results  in  general  symbolic  characterizations 
of  resource  utilization.  Varying  degrees  of  precision  are  possible,  but  at  a  cost.  The 
drawback  to  symbolic  analysis  is  that  in  general  it  is  unsolvable,  and  for  many  restricted 
domains  it  is  computationally  intractable. 

6  Toward  Realizing  a  PEA 

We  analyze  the  general  ca  pabilities  required  of  a  PEA .  These  capabilities  include  a  knowledge¬ 
base  representation  of  performance-related  information,  demand  and  data-driven  analysis 
modes,  and  the  ability  to  instrument  a  specification  for  metering.  As  described  earlier,  spec¬ 
ifications  will  need  to  include  performance  constraints  (or  goals)  and  any  assumptions  that 
can  be  made  about  the  run-time  environment  of  the  target  system.  The  knowledge-base 
serves  to  represent  the  functional  constraints  (which  define  the  desired  functionality  of  the 
target  system)  along  with  annotations  that  describe  the  performc.nce  constraints  and  en¬ 
vironmental  assumptions.  These  annotations  may  be  automatical'y  propagated  down  into 
the  abstract  syntax  of  the  functional  constraints  by  constraint-propagation  demons.  Only 
simple,  relatively  cheap,  but  generally  useful  inferences  would  be  made  via  this  date-driven 
mode.  Other  kinds  of  analysis  are  more  expensive  to  make  and/or  more  rarely  useful  and  so 
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there  must  he  some  explicit  outside  sTmuius  to  perform  .h  . 
from  the  initial  specifica* ion.  from  the  user  oi  fiom  .•  yie-  u 
it  can  fie  applied.  Hie  idea  is  tha1  various  ap>i\  i  ap  .  ;• 

sense  I  he  Knowledge  base  allow-  quern-.  .rom  us  ■[<  t- 
interested  facet  regarding  performance  knowledge  v 


When  a  specification  i<  transformed,  the  resul .  is  a  rep  .  •  ; 
Performance  analysis  typically  needs  u.  h<*  done  in  o:e  r 
tion  invariants.  The  representation  is  tie  r.  rcm.-lyced  1.. 
annotations  up  to  date — to  supper1  further  dt-civn  ma> • . 
able  to  respond  to  th**  application  oi  a  transformation.  ref- 
annotation  invariants  have  been  convent!  i.aiizex 
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In  summary,  we  believe  that  a  general  PEA  will  support 
the  knowledge-base  manager 
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•  demons  which  automatically  propagate  cons:  -i/-. 

•  demand-driven  analysis  and  propagation 

•  maintenance  and  query  ing  of  perfo;  .nan  ,.y 

•  automatic  instrumentation  of  a  specification  f-v  uc 
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describe  a  design  rule  for  divide-and -conouer  a!,  .nthm-  men  show  how  .  car.  be  ext 


er 


w'th  performance  estimation /analysis  capabili' ;  ,v>  1  finally  describe  the  derivation  o: 

mergesort  algorithn.. 


A  design  rule  for  divide-and  conquer  algorithms  derives  an  instance  of  the  following  progran 
functional  scheme: 


DC(x)  ::=  if  Pnmiiive(x) 

then  Directly  —  Solve(x) 

else  Compose  o  [G  x  F]  o  Dccornpofic(x) 


a*1  A-L"A.-.  mm-m. -u  riWi'i  'n  ft  ~~n  ~‘i  b1  'f  ‘Si  ■**  ~Nir~*  '"l‘ 
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where  G  may  be  a;  arbitral  function  '•pu.-.'iy  :•  rher  •  a.-*  den»ity  function  Ici  o.  F 
f  o  g,  called  the  con.',  eve  ion  of  /  and  t'eno:*"*  the  'unction  :esui  ing  from  applying  f  to 
the  result  of  applying  g  to  its  argument  \f  x  raned  t  he  p-odimt  of  f  and  g .  is  defined  by 
[/  x  p](i,y)  =  <  f(x).ggj)  >.  Deromp^sf  ;s  refrn e  *.o  as  tl*-  decomposition  operator,  G  is 
referred  to  as  the  auxiliary  operator.  Comvos.'  jeiwitd  to  as  tt.e  composition  operator,  and 
Dircctly-Solvt  is  referred  to  as  the  prinoMve  opera’ or.  in  order  to  construct  an  instance  of 
this  scheme:  First  choose  a  simple  decompo.:*  h,  ■-  •  rater,  and  choose  an  auxiliary  operator, 

then  use  constraints  to  derive  input  and  ontp:;-  ...mi  ous  for  the  composition  operator. 

The  performance  of  a  divide- and- .one:  ;  .  -.igorithn  can  also  described  by  means  of  a 
scheme.  Let  5/r(nl  denote  the  maximum  size  of  an  ou'put  of  program  F  as  a  function 
of  inputs  of  size  n..  Similarly.  n  r  Yp  r: !  d-nule  the  maximum  amount  of  time  required  by 
program  F  to  compute  an  output  for  an  input  of  size  n.  The  worst-case  output  size  and 
time  complexity  of  a  divide- and-cenquer  algorithm  are  described  by  the  schematic  recurrence 
relations: 

S:->r'ctiv- Solve 'T<.‘  :f  Primitive 

[  Scomw  o  [5o-  y  Sr]  O  Sr1,:,„,r.„t(n)  if  -‘Primitive 


{To>re ciii-so.vtin)  if  Primitive 

Tpcco --  Plu*  o  [F 7  X  Tr\  &  •>.'U^mp,,,hnVr 

Tcjmpoit  0  [-cr,  X  .cr;  0  >/,rf ,.i  n)  if  -  Primitive 

1  hese  schemes  are  used  in  two  wavs.  Fiof  for  analysis  purposes  abler  a  divide-and-conquer 
algorithm  has  been  constructed,  the  schemes  aie  instantiated  and  the  recurrences  soived 
to  give  an  exact  output-size  and  time  analysis,  Second,  for  estimation  purposes:  if  we 
have  a  performance  bound  to  be  met  and  a.  simple  ■ ‘composition  operator  has  been  chosen 
i according  to  the  design  rule)  then  the  recurrences  van  be  u-ed  to  determine  performance 
bounds  on  th**  specification  for  the  composition  o(x“:a..-r 

Now  we  may  apply  this  to  ;>  particular  problem,  '"n,  roue  that  we  start  with  the  following 
specification  ter  the  piobierr  of  sorting  a  sequent*-  of  numbers: 

SOHlfx;  ~  z  such  that  Ptnnut.^'on^x ,  -r)  A  Ordcrtd{ z  t 

Suppose  furthermore  that  we  want  to  derive  a  scr,  altrorithm  whose  worst-case  asymptotic 
time  behavioi  is  optimal.  Suppose  furthermore  that  a  0)n:)  sort  algorithm  has  been  derived 
elsewhere  in  the  search  tree.  Now,  following  the  design  rule  we  begin  to  design  a  divide  and 
conquer  sort  algorithm  by  choosing  a  simple  decomposition  operator  on  sequences.  Suppose 
that  the  decomposition  operators  FirslRest  and  LiStSpiit  are  known  to  the  system  and  have 
the  following  performance  information  associated  with  them: 


PF,r.iRr„{n)  =  (l.n  -  1; 


T t  ,r»(ftr»l  ('0  —  1 


^••tSphtV*V*  —  \r*  *■  n/'  •*)  *  1  •  1 


Suppo-  t r.at  we  choose  FirstRest.  This  choice  leans  tc>  th  '  tcs./ 
algorithm  The  design  rule  performs  some  formal  mampma'  :  th  ,,  1 

specified'. !  -I.  hr  the  composition  operator  ,  which  inserts  a  mum.--:  ’-.i  <  •  :  ; 

In  para *. V  extended  rule  would  derive  a  hound  on  the  per1'  •  ■  .  :  ,  o  1 

as  follow  -  !  -. -’antiatmg  the  time  analysis  scheme  we  obtain 

Tsopr(n)  =  1  4  1  -r  TsohtW  —  1 :  -*•  T,n s  *  -  1 

where  ;  .  :s  the  time  complexity  of  the  composing  a  operator  h-  -  :  linr 

Tsori  '  must  better  0(n2)  we  plug  n2  ,n  for  T$ort'  ■>  •  *»'.d  s  "  :  upper  bm, 

T’n,.-: 

n2  =  1  +  1  -f-  (n  -  1  l2  r  7  Irxie-i  i  1  •  u  —  t 

or 

Tjntfrt{  l.n  -  1)  -  u 2  -  t  A  -  i  )2  2  ~  2  n  -  ; 

So  in  <•:  i-r  to  produce  a  sort  algorithm  better  than  (Jin2),  an  Insert  b* : vt 

0  rii  n.U't  '•»>  synthesized.  A  short  way  into  the  oen  vat  ion  of  !■  s  —  we  m  iha;  tin 
possibh-  Simple  algorithms  for  Insert  take  at  h  ast  0(n)  timeh  •  S.ic  .  m-  of  aeveke 
car.  h<‘  n;-  :r.ed  and  attention  focused  elsewhere. 

Suppos.  •  hat  we  backup  to  the  design  rule  and  choose  Lis. Split  as  d-.-'ompcitic.-.i  ot  * 
The  ana'  .sous  performance  calculation  for  the  composition  opera. o;  :c<th?-<i  Merge'  vi 
bound  e'  (t  >, 2 .  in  order  to  obtain  a  sort  algorit hni  faster  than  C  ••  i  This  bound  i< 
achieve-;  and  m  fact  a  0(n)  Merge  algorithm  can  be  derived  »  ::  the  same  ch  •  id' 
ec.nquer  design  rule  [7], 

An  exa  '  analysis  for  the  completed  mergo:-.,rt  algorithm  if  perfo; as  follows  V-  . 
derive. •  of  Merge  we  get 

S\f,rge(n,m)  =  n  -f  rn  7\lr,s.[ii,  m)  =  v,  - 

Plugsrit.c  i  hr>e  and  other  values  into  the  analysis  schemes  tor  divide- ami--  neper  w« 

P  \i  aort{^  I  -S  vf  erge  ®  i  d  M  j  ^  *S  ,\f  sorl  j  0  V  U  ) 

^Mrrgc  '  M  a  -i  V  r  (  j  {  n  /  2  ,  U  /  2  ) 

P  M  aorl  (  n  /*.  )  S  S  ,Vf  50»-(  ( rt  /  2  ) 


which  Ini  -  solution  SM»o*-t(n)  =  n. 


•  M*ort{n)  TiJtiiSpht{n)  4  Plus  o  \T\i §ort  x  T\f*c>ri]  e  .  i  i n  ,1  n 
T\jtrge  ®  |SmiotI  X  F\f,CT.(]  C  S Pnt.S'p/>f(ri  ) 

—  1  +  27'M»or((n/2)  4  TMergr(n/2,  n/2) 

=  14  27m  •ort  (n/2) 4  n 


which  has  solution  7.s„,|(n)  -  O(nlgn).  In  summary,  this  example  shows 


1  how  oerlorma,. <:  capability  ran  b e  b  ;j* :  into  a  umign  n.  m; 

2  how  these  estirna: e--  can  be  used  u>  guide  and  pvutn  *~ar*u  space; 

3.  hou  to  perorin  exact  performance  a.mlvsis  cmroa  ,-c  oroc  tarns. 


8  Future  Work 


Clearly  there  is  much  work  that  remains  to  be  done  before  a  general  robust  PEA  emerges 
from  the  laboratory  At  the  end  of  the  current  project  v.e  expect  the  following  results. 


1.  Demonstration  of  the  feasibility  of  the  qualitative,  statistical,  and  symbolic  approaches 
to  performance  est imtu'oij; 

2.  Demonstration  of  too  feasibility  of  fully  automatic  tools  for  performance  estimation; 

3.  Deli /erabie  nrototvpes  for  guiding  the  Heveiopmen*  of  tow- level  optimizations,  data 
structure  selection,  and  control  structure  optimization: 
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KBSA  Perspective  Panel 
Introduction 


I.  How  has  KBSA  Vision  Changed? 

A.  Vision  5  years  old 

B.  Vision  as  stated  in  KBSA  report: 

1.  New  Paradign 

a.  Informal  person-based  =>  formalized 
computer-assisted 

b.  " Machine-in- the-loop" 

c.  Build  "Corporate  Memory"  of  decisions  rationale 

Use  for  development  maintenance 

d.  Requires  knowledge-based  assistant 

2.  New  Software  Life  Cycle 

a.  Formal  Specification 

Executable  as  prototype 
Validated  via  usage 

b.  Implementation 

Derived  from  formal  spec  via  transformations 
Testing  disappears 

c.  Maintenance 

Modify  formal  spec  rederive  implementation 

3.  Major  Effects 

a.  systems  will  be  larger,  more  integrated, 

longer  lived  arise  from  many  small 
evolution  steps 

b.  Software  will  finally  remain  "soft" 

c.  Evolution  will  become  central  software  activity 

d.  Evolution  will  also  become  basis  for 

initial  development 

C.  Vision  today 

1.  Remarkably  intact  (i.e.  unchanged) 

For  saw  emergence  of  formal  process  model 

2.  Some  Laboratory  Experience  with  parts  of  vision 

a.  Executable  Specifications 

Refine:  Kestrel 
Setl:  NYU 
APS:  ISI 
ELI:  Harvard 

b.  Corporate  Memory 

FSD/CLF:  ISI  (maintenance  context) 
EES:  ISI  (explanation) 

c.  Evolved  Specification  (Prototype)  Delivered 

Refine:  Kestrel 
Ada  Compiler:  NYU 
FSD/CLF:  ISI 

d.  Knowledge-Based  Development 

Programmer's  Apprentice:  MIT 

3.  No  experience  with  vision  as  a  whole 
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4.  New  Insights 

a.  Acquiring  decisions  rationale  is  hard 

Both  representation  elicitation 

b.  Modifying  Specifications  is  hard 

Lack  of  optimization  only 

helps  localize  information 
Specs  have  structure 

c.  Compiler  Advice  (annotations)  is  an  alternative 

to  transformational  derivation 

II.  Hew  is  KBSA  Program  Progressing? 

A.  Program  3  years  old 

B.  Program  generally  following  plan 

1.  Several  independent  efforts 

Each  focused  on  a  facet 
Each  embodying  a  framework 

2.  4  of  7  identified  facets  funded 

Plus  one  about  to  be 

Most  short  term  (3-5  year)  milestones  met 
Exception:  subroutine  module 

decomposition  advice  within 
Performance  Facet 

3.  Framework  definition  concept  demonstration  effort  started 

4.  Supporting  technologies  not  explicitly  funded 

5.  Bilateral  facet  communication  (batch)  just  being  initiated 

6.  Cannon  problem  domain  selected  (Air  Traffic  Control) 

C.  Prognosis 

1.  Optimistic 

a.  On  track 

b.  "Phase  Coupled"  integration  feasible 

c.  Overlapping  development  provides  basis 

for  comparison  understanding 

2.  Pessimistic  (Hard  issues  yet  to  come) 

a.  Integration 

Standards 

Framework:  no  closer  to  consensus 
than  before 

Common  User  Interface:  not  separated 
from  faaet 

Mechanism  not  yet  identified 
Interleaved  operation 
Ability  to  process  partial  descriptions 

b.  Engineering 

Distributed  Framework 
Scaling 


KBSA  TRANSITION 


Samuel  A.  DiNitto,  Jr. 


Historically,  tae  transition  of  software  engineering  technology  has 
lagged  not  only  hardware  engineering  technology ,  but  has  even  lagged 
advancements  in  software  applications.  We  have  examples  of  software 
engineering  tools  and  techniques  that  demonstrated  their  worth  in  the 
early  1970 's  and  are  still  .nor  widely  used,  if  at  all.  We  have 
programming  languages  that  began  to  be  heavily  used  only  about  the  time 
they  became  politically,  if  not  technological iy  obsolete.  We  also  find 
that,  as  new  "software  engineer?"  or  software  engineering  components  of 
established  industries  crop  up,  they  make  the  same  mistakes  and  often 
limit  themselves  to  the  same  technologies  used  in  the  early  1960's, 
namely,  a  compiler  (maybe)  and  a  linking-loader  (usually). 

A  cursory  analysis  of  tne  reasons  for  this  lack  of  techology  transition 
leads  to  at  least  tne  following,  overlapping  reasons: 

1.  'Jnawareness  cf  the  technology. 

2.  "Culture  shocx."  (That's  not  the  way  we  did  tilings  in  the  past.) 

3.  Initial  cost  of  tools  training,  etc. 

4.  Lack  of  "support"  for  the  recnnolcgy  t.ta  inter.ance ,  training,  etc.) 

5.  Lack  of  nard  data  or,  cost  vs.  productivity  improvement. 

6.  No  push  from  the  competition. 

7.  No  "serious"  demand  from  the  customer  for  high  quality  or  high 
productivity. 

8.  Incompatibility  with  the  development  hardware. 

All  of  these  reasons,  and  more,  will  be  used  against  the  KBSA  technology. 

Unless  there  is  a  very  unlikely  drastic  change  (for  the  better)  in  terms 
of  a  willingness  to  spend  huge  sums  of  money  on  large,  "real"  systems  to 
try  out,  and  prove,  new  technology,  the  transition  of  the  technology 
will  depend  very  heavily  on  the  ability  to  make  the  KBSA  paradigm  widely 
available,  at  low  cost.  By  "low  cost"  is  meant  the  cost  of  the 
necessary  hardware,  sottware  licenses,  training,  support,  and  what  might 
be  perceived  as  "additional"  manpower  needed  to  support  the  paradigm. 
Thus,  this  factor,  which  is  a  combination  cf  3,  4,  and  8  above  and  which 
will  oe  labeled  "cost  of  use,"  is  the  key  to  transition  or  nontransition 
of  this  technology.  With  a  low  cost  of  use,  all  the  ether  deterrents  to 
software  engineering  technology  transition  can  be  overcome  with 
additional  effort:  without  it,  the  odds  of  successful  transition  are 
small . 

If  we  look  at  the  past,  at  a  simple  tool  like  the  misnamed  "path-tester" 
that  provided  a  measure  or  ho w  we. 1  the  software  was  tested,  the  above 


point  is  brought  home.  Discussions  with  software  c .eve’opero  revealed 
that,  even  though  the  cost  of  a  license  (usually  srouid  Ft-:'  war  jow, 
there  was  reluctance  to  spend  the  money.  Even  after  dna  mo-oy  was 
spent,  the  tool  was  often  not  used  because  additional  manpower  would  ce 
spent  in  using  it,  and,  after  all,  the  customer  didn't  require  a 
demonstration  that  each  piece  of  code  was  tested. 

Software  quality  metrics  technology,  which  attempts  to  take  quantitative 
measures  of  those  quality  attributes  held  so  dear,  (reliability, 
maintainability,  efficiency,  portability,  etc.),  provides  another  recent 
example.  When  told  that,  for  a  cost  equal  to  about  five  per  cent  of  the 
software  development  expenditures,  a  system  program  manager  could  have  a 
capability  to  specify,  predict  along  the  way,  and  assess  the  final 
software  quality  before  acceptance,  two  kinds  of  responses  were  given. 
From  those  who  saw  the  problems  of  many  military  software  acquisit :cns , 
came  responses  like  "cheap  at  four  times  tne  price."  From  those  tied  up 
in  their  own  single  system  development  came  comments  like  "too 
expensive"  or  "outrageous"! 

Finally  (although  not  all  that  comes  to  mind),  there  is  still  today 
being  fought  the  battle  over  the  use  of  a  high  order  language  versus 
assembly  language  in  certain  military  applications.  The  same  arguments 
that  have  existed  for  over  20  years  are  made  again: 

1.  The  cost  of  the  compiler  (development,  retarge. t ting ,  license;  . 

2.  The  cost  of  training  and/or  getting  experienced  people. 

3.  The  cost  of  additional  hardware  to  take  care  of  the  additional 
memory  that  will  be  needed. 

Of  course  there  are  other  reasons  given,  as  well. 

1.  Immaturity"  of  the  language/ compiler . 

2.  Lack  of  personal  experience  (confidence)  w; th  the  compiler/ 
language . 

3.  The  people  to  be  used  have  already  delivered  a  similar  system 
using  assembly  language  or  a  different  language. 

However,  without  "breaking  the  ice"  with  tnat  first  use,  which  always 
equates  to  overcoming  actual  or  perceived  costs,  one  can  never  attack 
tne  latter  set  of  obviously  overlapping  and  related  reasons. 

The  position  taken  is  thus  very  simple.  Without  keeping  the  "cost  of 
use"  down  to  a  reasonable  level,  the  chance  may  never  come  to  actually 
demonstrate  the  benefits  of  the  KBSA  technology.  Or  in  other  words,  the 
chances  for  a  successful  technology  transfer  are  inversely  proportional 
to  the  perceived  cost  of  use. 
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PROBLEMS  AND  PROSPECTS  FOR  TECHNOLOGY  TRANSFER  IN  EXPERT  SYSTEMS 


ROBERT  J.  GLUSHKO 
SOFTV'ARE.  ENGINEERING  INSTITUTE 


Technology  can  be  defined  as  the-  application  of  knowledge  to  solve  a 
practical  problem.  Thus,  the  development  and  deployment  of 
knowledge-based  or  expert  systems  is  a  pure  form  of  technology 
transfer  in  which  the  knowledge  bairm-  transferred  is  made  explicit. 

Technology  transfer  is  usually  more  difficult  and  often  takes  longer 
than  either  the  developers  of  the  technology  or  its  recipients  want  to 
believe.  Unfortunately,  the  challenges  or  technology  transfer  are 
even  greater  for  expert  systems,  wmch  face  barriers  above  and  beyond 
those  that  impede  the  successful  development  and  deployment  of 
conventional  software  systems.  In  this  paper  I  discuss  some  of  these 
special  problems  for  technology  transfer  in  expert  systems,  noting 
where  possible  the  prospects  for  overcoming  them. 

The  successful  transfer  of  technology  as  knowledge  embedded  in  an 
operational  software  system  is  the  culmination  of  a  long  series  of 
activities.  Primarily,  there  include  defining  the  "rignt"  system 
requirements  in  response  to  the  user's  needs,  developing  the  system 
that  meets  those  requirements,  deploying  the  system  in  the  user's  work 
environment,  and  then  using  and  maintaining  the  system  during  its 
deployed  lifetime.  Each  of  these  activities  is  more  complex  for 
expert  systems  than  for  conventional  software  systems. 

Getting  the  requirements  right  is  difficult  for  expert  systems  because 
both  developers  and  users  typically  have  unrealistic  expectations 
about  how  much  knowledge  can  be  embodied  and  transferred.  Many  people 
have  noted  the  "overselling  of  AI , "  but  unfortunately  some  overselling 
was  and  is  still  inevitable,  both  for  companies  in  the  AI  business 
trying  to  sell  systems  and  for  people  within  potential  customer  firms 
trying  to  generate  management  support  for  AI  efforts. 

Expert  systems  are  new  technologies,  and  part  of  the  maturation  cf  any 
technology  is  learning  how  and  why  it  works  along  with  its 
limitations.  Overselling  by  expert  system  enthusiasts  and 
entrepreneurs  helped  to  establish  the  boundaries  for  suitable 
problems.  Choosing  the  right  problem  for  an  expert  system  is 
essential,  but  the  level  of  awareness  and  experience  in  most  potential 
customer  firms  is  low.  Expert  system  vendors  often  need  to 
"cultivate"  customers  to  make  them  able  to  assess  what  they  might  be 
buying.  Raising  management  awareness  is  an  essential  activity  for 
vendors  as  a  form  of  risk  management,  cc  that  customers  won't  expect 
more  than  can  be  delivered.  If  is  especially  important  to  target 
upper  management  for  "AI  awareness,"  because  these  are  the  people  who 
must  provide  support  and  sponsorship  to  make  an  expert  system  effort 
successful,  and  they  ate  extremely  unlikely  to  have  any  knowledge  or 
experience  about  the  potential  and  limits  of  AI.  Strong  management 
support  will  be  critical  during  the  knovGeage  engineering  phase, 
because  domain  experts  are  always  valuable  and  expensive  employees  of 
the  customer  organization,  and  the  pressure  is  always  there  to  return 
them  to  their  "real"  jobs  where  their  expertise  is  needed  now. 
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Once  the  customer  achieves  sufficient  awareness  to  r-  v>, 

requirements  definition  for  an  expert  system,  two  acditi  r  .  :  t . 

arise.  It  is  hard  to  know  how  much  knowledge  engineer :  .v  .  r  •  ■  . 
because  sometimes  there  just  aren't  good  rules  for  sc  l v  ■  •»  p  Jt  an 

or  because  the  experts  don't  agree  on  the  rules.  ?■'  J .  tier. ..  I:.,  re 

are  no  good  ways  to  measure  how  much  expertise  cuqb*:  to  .■(-  captu-1  1 . 
without  techniques  to  decide  how  much  mere  an  t:.'(  rt  solo-jt 
worth,  how  can  a  customer  decide  how  much  to  :.ti  caiio,  nr 

expertise?  How  much  knowledge  engineering  is  cost  effective?  foe: . 
for  determining  return  on  investment  in  expert  system  problem,  domains 
are  nonexistent. 

Assuming  that  the  customer  and  vendor  can  come-  up  with  a  pie  in:  inv.y 
set  of  requirements,  still  other  barriers  to  successful  tecr.nsj.ocy 
transfer  emerge.  Foremost  is  the  "culture  clash"  between  the 
developers  of  the  expert  systems  and  the  domair  experts.  Tb*: 

stereotype  of  the  AI  hacker  is  receding,  but  many  a  potential  sale  he  a 
been  lost  because  software  developers  were  hastily  s<-nt  th: 

customer  site  to  give  demos  or  talk  to  users.  Evpari  .cy stems  hav*> 
only  recently  begun  to  penetrate  the  commercial  data  prr: cc as ing  yr.:.<c 
even  though  many  activities  in  typical  compute:  centers  are  pc  r  '  :.c 
expert  applications,  such  as  capacity  planning,  performance  tuning, 
and  scheduling.  The  culture  clash  between  the  •*.  •  and  DP  wet  id' 
remains  the  major  impediment. 

Another  harrier  to  successful  technology  transfer  for  expert  sv.-. corns 
is  the  reliance  on  hardware  and  software  that  is  out  of  the  mainstream 
of  computing.  LISP  machines  and  special  expert  system  development 
environments  are  essential  to  support  the  rapid  prototyping  that 
characterizes  expert  systems,  but  represent  huge  barriers  to 
successful  deployment.  Some  AI  companies  have  already  failed  because 
they  were  wedded  too  tightly  to  proprietary  hardware  or  software. 
Those  who  survive  the  shakeout  will  no  doubt  follow  the  developing 
trend  to  convert  expert  systems  to  run  cn  convent  lor  e!  32-bit  machines 
and  tc  replace  LISP  with  C. 

The  problems  with  novel  hardware  arid  software  art  compounded  after  the 
system  is  deployed.  Few  customer  organizations  ha\e  pre-existing 
expertise  to  support  LISP  machines  or  expert  system  environments, 
bore  fundamental  a  barrier  to  technology  transfer  is  the  fact  that 
"maintenance"  problems  in  deployed  expert  systems  are  far  more  likely 
to  he  problems  of  knowledge  engineering  than  problems  of  software 
engineering.  That  is,  user  problems  are  usually  "buggy  rules"  rather 
than  "buggy  code."  This  situation  requires  that  the  system  vendor 
train  the  users  to  be  knowledge  engineers  so  they  can  maintain  their 
own  systems.  AI  companies  are  making  concerted  efforts  to  develop 
"user-friendly"  expert  system  shells  with  templates  for  rules  so  that 
"Knowledge  management"  can  be  as  commonplace  as  database  management 
for  the  customer  organization. 

I  hope  that  my  litany  of  the  problems  that  challenge  the  successful 
transfer  of  technology  in  expert  systems  is  not  discouraging.  I  noted 
'hat  some  of  these  problems  are  being  overcome,  or  are  beinq 
transformed  into  opportunities  by  innovative  vendors  and  developers. 
rinallv,  le'-'s  hope  that  we  all  learn  from  each  other  at  this 


I  gratefully  acknowledge  the  help  provided  by  Dr.  Laura  Silver  of  the 
Carnegie  Group  and  William  Hefley  of  the  Software  Engineering 

Institute. 
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R.  W.  Lawler 

Boeing  Computer  Services  Co 


Technology  Transfer  and  the  Knowledge  Based  Software  Assistant 

(KBSA) 


In  1983,  Boeing  established  an  Artificial  Intelligence  Center  to 
take  a  leadership  role  in  bringing  AI  technology  to  The  Boeing 
Company.  The  center  was  to  develop  advanced  technology  and 
accelerate  the  infusion  of  that  technology  into  the  Boeing 
Operating  Companies. 


Boeing  is  a  decentralized  company  with  a  small  corporate 
headquarters  and  six  operating  companies.  Boeing  Commercial 
Airplane  Company  (BCAC) ,  Boeing  Aerospace  Company  (BAC) ,  Boeing 
Vertcl  Company  (BVC) ,  Boeing  Military  Airplane  Company  (BMAC) , 
Boeing  Electronics  Company  (BECo) ,  and  Boeing  Computer  Services 
Company  (BCS) .  The  AI  center  was  placed  in  the  BCS  Advanced 
Technology  Center  for  Computing  Sciences  (ATC) .  In  1964,  a 
company  study  group  was  formed  to  determine  how  the  Boeing 
operating  companies  could  make  best  use  of  AI  technology.  This 
study  produced  two  major  results:  an  identification  of  six 
initiatives  that  would  exert  a  major  pull  on  AI  technology  and  a 
concept  for  technology  transfer  management. 


One  of  these  initiatives  was  the  Knowledge-Based  Software 
Engineering  Initiative  which  is  similar  to  the  RADC  KBSA.  This 
initiative  produced  the  "Crystal"  technology  which  was 
demonstrated  at  the  KBSA  conference  in  1986. 


Figure  1  illustrates  the  model  for  management  of  technology 
transfer.  Figure  2  represents  an  instance  of  this  model  in 
action  for  application  of  AI  to  maintenance  and  diagnosis.  Note 
that  in  less  than  one  year  the  technology  was  transferred  to  all 
operating  companies;  that  technology  was  being  shared  between 
operating  companies;  and,  feedback  occurred  that  influenced  the 
ATC  designed  based  diagnostics  R&D  project.  This  bottom  up  rapid 
deployment  of  technology  occurred  because  the  theory  and  tools 
were  sufficiently  mature  for  this  application  area,  and  there 
were  no  barriers  to  the  use  of  the  technology.  The  KBSA  does  no 
enjoy  a  similar  environment.  Development  and  transfer  of  this 
technology  will  require  a  more  managed  approach. 


A)  Applications  to  Army  Aviation  Systems  fault  Isolation 


The  following  issues  will  be  discussed  in  the  panel  presentation. 

issue  1  -  Technology  Packaging 

The  concept  for  technology  packaging  affects  the 
rapidity  of  transfer.  Figure  3  illustrates  this.  The 
extremes  are  transfer  to  other  R&D  labs  of  research 
results  and  transfer  of  technology  packaged  in  systems 
for  building  applications.  Which  parts  of  KBSA  should 
be  packaged  at  what  level? 

Issue  2  -  Incremental  vs  Revolutionary  Improvement  in 
Software  Productivity 

KBSA  technology  has  the  potential  to  improve  software 
development  productivity  significantly  by  radically 
changing  the  way  we  develop  and  maintain  software.  It 
can  also  be  fielded  as  incremental  improvements  in 
current  software  development  automation  tool  sets.  A 
radical  change  will  require  major  revisions  to 
procurement  regulations  and  standards.  Will  a  radical 
change  be  more  beneficial  than  incremental  improvement' 

Issue  3  -  Commercial  vs  Military  Applications  of  KBSA 

Military  procurements  of  new  weapon  systems  require 
diverse  leading  edge  technologies  that  impact  one 
another.  This  impact  is  "discovered"  dutifig  the 
procurement  process  and  requires  formulation  of 
innovative  concepts  for  applying  technology  to  provide 
new  functionality  and  performance.  Is  KBSA  technology 
better  proved  in  this  high  risk  environment  or  in  a 
commercial  environment  that  requires  few  interacting 
technological  innovations? 

Issue  4  -  Model  for  Transfer  of  KBSA  Technology 


The  ATC  model  has  been  quite  successful  as  a  "managed" 
approach  to  technology  transfer.  What  are  some  of  the 
alternative  ways  this  model  could  be  modified  to  apply 
to  transfer  of  DOD  sponsored  technology  to  industry 
and/or  sharing  of  industrial  development  of  the 
technology? 
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FIGURE  3  TECHNOLOGY  PACKAGING  ENVIRONMENT 


SELECTION  OF  INVESTMENT  STRATEGIES  WHICH  ARE  OPTIMAL  FOR  THE 
IMPLEMENTATION  OF  SOFTWARE  SUPPORT  ENVIRONMENTS 


ABSTRACT 


Kenneth  E.  Nidiffer 


Software  Productivity  Consortium 
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The  objective  of  the  research  was  to  further  the  depth  of  understanding  of  the 
variables  that  impact  the  problem-solving  process  leading  to  the  investment  strategy 
decision.  An  investment  strategy  decision  is  made  for  almost  every  defense  system 
acquired  by  the  Department  of  Defense  (DoD)  with  respect  to  the  identification  of  what 
software  support  environment  will  be  used  in  development  and  in  support  of  the  mission 
code  associated  with  the  defense  system  and  what  level  of  standardization  will  be 
employed  by  DoD  with  respect  to  the  selected  software  support  environment. 

Numerous  kinds  of  software  support  environments  have  emerged  in  recent  years  to 
help  solve  problems  being  experienced  by  developers  and  supporters  of 
software-intensive  defense  systems.  Although  modern  software  support  environments 
increase  productivity,  ihey  are  expensive  to  build,  deploy,  and  support  and  are  often 
unique  to  the  specific  defense  system  under  development.  The  investment  strategy 
decision  process  is  concerned  with  achieving  the  optimal  balance  between  productivity 
and  life-cycle  costs.  The  government  defense  system  program  manager  is  required  to 
form  a  working  group  to  support  the  investment  strategy  decision  process:  however, 
this  process  in  supported  by  many  ill-structured  activities  that  inhibit  effective  decision 
making.  A  need  existed  to  perform  research  directed  at  answering  two  questions:  (1) 
what  is  the  proper  investment  strategy  decision  process  and  (2)  what  is  the  proper 
investment  strategy  decision?  This  research  addressed  these  questions  by  (1) 


V  V 


developing  an  econometric  model  based  on  insights  gained  about  the  variables  that 
impact  the  investment  strategy  decision  process  and  (2)  designing,  building,  verifying, 
evaluating  and  validating  a  program  manager's  decision  support  system.  The  decision 
support  system,  which  is  named  the  "  DoD  Software  /nvestment  Decision  (DSID)." 
model  incorporates  the  econometric  model  and  operates  on  a  set  of  independent  data 
files  that  can  be  updated  as  new  information  becomes  available.  The  DSID  model 
supports  the  program  manager  by  providing  a  frame  of  reference  to  construct  the 
problem  and  a  method  to  perform  "what  if"  exercises.  There  was  no  attempt  to  change 
the  process  only  to  provide  the  program  manager  with  a  decision  aid  that  encompasses 
more  formalism  by  which  unstructured  and/or  semi-structured  problem-solving  activities 
are  provided  with  structure.  It  is  too  early  to  judge  whether  the  DSID  model  will  prove  a 
successful  support  system;  however,  considering  the  favorable  results  obtained  from 
typical  users  and  from  evaluation  of  investment  strategy  decisions  made  on  several 
defense  programs,  it  is  argued  that  the  DSID  model  has  significant  potential  with 
respect  to  improving  the  investment  decision  process.  The  DSID  model's  point  of  view 
is  decidedly  that  of  the  government  program  manager  and  his  superiors,  but  analysts 
and  industry  program  managers  who  wish  to  understand  some  of  the  pressures  that 
effect  standardization,  productivity,  and  life-cycle  costs  in  the  DoD  community  may  also 
find  this  research  of  interest. 
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Abstract 

This  paper  describes  the  implementation  deLails  of  the  KBSA  Common  Framework  The 
system  form*  a  distributed  knowledge  base  for  knowledge-base  programming  tools  and  executes 
on  multiple  Symbolics  workstations  Within  the  system  we  have  attempted  to  merge  together 
an  object-oriented  programming  environment  supporting  the  representation  of  project  data,  with 
a  logic  programming  environment  to  support  data  consistency  and  control  of  the  programming 
process  W'e  describe  the  internal  organiiation  of  the  system  and  some  of  the  implementation 
decisions  we  have  made  We  conclude  with  future  capabilities  we  plan  tc  introduce 


1  System  Overview 

The  KBSA  Common  Framework  is  written  in  Common  Lisp,  and  currently  runs  on  Symbolics  workstations 
The  prototype  is  still  in  its  early  stages  of  development  and  therefore  leaves  many  issues  unaddressed  In 
writing  this  paper,  we  describe  the  strategies  we  have  used  to  obtain  a  distributed  framework  and  some  of 
the  design  decisions  we  have  made  A  more  complete  discussion  of  the  underlying  motivations  can  be  found 
in  Huseth87,. 

The  prototype  combines  several  programming  paradigms  into  a  single  system  by  combining  object-oriented 
programming  via  CommonLoops  ’Bobrow85  .  logic  programming  via  LogLisp  !Carciofini86!.  and  imperative 
programming  using  Common  Lisp  ]Steele84  Each  of  these  components  have  been  combined  in  a  dynamic 
distributed  system  The  framework  supports  object  instance  distribution,  and  a  minimal  capability  to 
dynamically  distribute  object  schema.  Objects  created  on  one  workstation  can  be  accessed  and  modified  on 
any  workstation  in  the  network  All  the  other  systems  will  automatically  riceive  the  updates  The  collection 
of  objects  making  up  the  system  is  referred  to  as  the  object  base  Loglisp  provides  the  ability  to  enforce 
logical  relationships  between  objects,  trigger  demons  satisfying  logical  predicates,  and  query  for  objects  using 
the  ob  ret  attributes 


2  Object  Distribution 

Distribution  of  objects  in  the  framework  is  done  at  the  object  level  User  defined  objects,  called  network 
objects  may  be  distributed  and  all  of  their  slot  values  uniformly  maintained  across  the  network  A  network 
object  slot  may  contain  value  types  of  integers,  strings,  symbols,  Lisp  cons  cells,  or  other  network  objects 

For  simplicity,  the  object  base  is  maintained  on  a  central  knowledge  base  called  a  server  The  workstations 
that  make  use  of  the  central  server  are  called  clients  To  obtain  efficient  access  to  object  instances,  local 
copies  ma\  be  requested  by  the  clients  When  a  client  first  references  an  object,  the  object  with  all  its 
slot  values  are  transferred  from  the  server  to  the  workstation  When  a  slot  value  within  the  object  contains 
another  network  object,  only  a  skeleton  of  the  referenced  network  object  is  created  in  the  client  The  skeleton 
object  is  identified  as  being  incomplete  and  must  be  retrieved  from  the  central  server  before  any  of  its  slots 
ran  b»  accessed  This  prevents  the  whole  object  base  from  being  sent  when  a  highly  connected  object  is 


requested  Once  an  object  has  been  referenced  for  the  first  time  subsequent  accesses  are  made  to  the  local 
copy  of  the  object 

Modifying  existing  objects  initiates  actions  which  are  required  to  maintain  consistency  between  the  local 
copies  of  the  object  instances  When  an  existing  local  object  is  modified  the  change  is  made  lot  alls  and  a 
message  is  sent  to  the  server  to  modify  the  central  cops  The  server  then  broadcasts  a  message  to  all  the 
other  workstations  to  invalidate  their  local  copies  of  the  object  The  next  time  the  invalidated  object  is 
referenced  by  an>  of  the  other  clients,  the  new  copy  will  be  retrieved  from  the  central  object  base 

Since  network  objects  in  a  Lisp  world  may  be  manipulated  like  any  other  Lisp  object  (i  e  placed  in  lists, 
arrays,  etc.)  we  must  take  care  to  ensure  that  the  uniqueness  properties  of  objects  is  maintained  Since  we 
control  the  distribution  and  manipulation  of  network  objects,  we  use  a  network  object  handle  to  uniquely 
identify  an  object.  Primitive  objects  such  as  integer  string,  symbols,  and  Lisp  cons  cells  that  are  directly 
manipulated  by  Lisp  cannot  be  guaranteed  the  same  rigorous  level  of  network  transparency  For  example, 
we  do  not  maintain  symbol  values,  properties,  or  function  definitions  across  the  network  Symbols  stored  in 
a  network  object  slot  must  therefore  only  be  used  for  their  identity  (i.e  EQness)  Similarly  we  only  maintain 
=  for  integers.  STRIHC-EQUAL  for  strings,  and  EQUAL  for  conses.  Any  side  effecting  operations  on  strings  or 
Lisp  conses  that  are  used  as  slot  values  will  not  necessarily  be  retained  by  the  object  base  and  as  such  are 
not  legal  ways  to  modify  an  object. 

3  Integrating  Objects  and  Logic 

The  programming  environment  supports  the  use  of  objects,  methods  and  instances  as  well  as  the  description 
of  the  objeds  using  logical  assertions.  Each  of  these  capabilities  are  discussed  further. 

In  an  object-oriented  system,  there  are  three  basic  entities:  classes,  methods,  and  instances  Each  of  these 
entities  are  supported  by  a  the  full  object-oriented  programming  style  provided  by  CommonLoops  on  a  single 
workstation.  Distribution  of  these  components  among  multiple  workstations  is  more  restrictive  When  an 
object  instance  is  created  it  is  entered  into  the  central  knowledge-base  making  it  available  to  all  the  other 
clients  We  have  not  yet  adequate!)  addressed  distribution  of  object  schema  or  methods  W>  have  several 
approaches  but  none  have  proven  satisfactory  for  performance  reasons 

The  logic  programming  facilities  of  the  framework  are  provided  by  LogLisp  LogLisp  is  a  logic  programming 
language  built  in,  and  integrated  with  Common  Lisp  Logic  is  used  in  the  framework  for  specifying  user 
queries  to  the  object  base,  for  triggering  demons,  and  for  describing  constraints  on  slot  values  Each  of  these 
capabilities  are  obtained  by  describing  a  list  of  predicate  clauses  The  predicates  may  contain  universally 
quantified  variables 

A  logic  program  is  a  collection  of  facts  or  declarations.  The  object  base  is  the  principle  source  of  these 
facts  We  are  then  able  to  write  predicates  or  rules  about  how  the  facts  are  viewed  For  example,  suppose 
the  knowledge  base  contains  an  instance  of  a  project  object  The  project  is  named  “Widget''  and  it  has  a 
manager  “Simth ."  The  object  representation  will  be 

Object  Claaa  Project 
Object  na at  :  "Widget" 

Object  manager  :  "Smith" 

The  prediale  logic  representation  of  these  facts  are  as  follows  The  “#?’  symbol  is  a  handle  to  the  network 
data  structure  containing  the  instance 

(project  »’  name  "widget") 

(project  manager  "Smith") 

1'  'S’ 
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Queries  can  easil)  be  constructed  to  request  all  projects  vihosr  manager  is  'Smith'  sue  project  name  i- 
'Wldge"  b> 

((.project  ’x  manager  "Smith")  (project  7x  name  "widget")) 

Integrating  objects  and  logic  is  a  key  aspect  of  our  logic  engine  In  order  to  ;  -*rfurm  these  logic  queries  o-i 
the  object  base  it  is  necessary  to  define  an  equivalence  between  the  logic  world  and  the  object  world  IVe 
current!)  do  this  b\  asserting  a  collection  of  rules  describing  the  structure  of  sri  object  ns  siois  anci  its 
super  classes  For  example,  given  the  following  object  definitions 

(defobject  A 
SI 

52) 

(defobject  (B  (include  A)) 

53) 

From  the  object  definitions,  the  following  logic  assertions  are  made  by  the  framework 

(A  ‘’instance  Si  ’value) 

If  (A-Instance  ’x) 

Artd(==  ’value  '  (A-Sl  ’instance)) 

(A  ’instance  S2  ’value) 

If  (A-Inetance  ?x) 

And(==  ’value  ' (A-S2  ’instance)) 

(B  ’instance  S3  ’value) 

If  (B-Inetance  ?x) 

And ( ==  ’value  ! (B - S3  ’instance)) 

(A- Instance  ’instance) 

If  (B-Inatance  ’instance) 

Note  that  =  =  is  the  general  Loglisp  equality  predicate,  and  !  signifies  that  the  following  expression  should  be 
evaulated  b>  Lisp  rather  than  logic.  The  A-Sl.  A-S2,  and  B-S3  symbols  name  Lisp  slot  accessor  functions 
In  addition,  an  A-Instanee  and  B-lnstance  fact  would  be  asserted  for  each  instance  of  object  class  A  and  B 
respective!)  that  are  created 

The  ability  to  use  the  Lisp  accessor  functions  with  the  logical  predicates  enables  us  to  avoid  complete 
duplication  of  th«-  knowledge  base  in  both  the  logic  system  and  the  object  system  Although  this  permits  us 
to  use  the  LogLisp  system  without  change,  it  does  require  a  large  number  of  mapping  predicates 

The  ability  to  use  logical  queries  enables  us  to  retrieve  objects  using  any  combination  of  their  attributes 
buch  a  capability  minimizes  the  need  to  retain  complex  accessing  relationships  to  objects  of  interest  Tie 
logical  predicates  are  also  used  to  create  demons  and  object  slot  assertions. 

A  demon  associates  a  logical  predicate  with  the  execution  of  a  method  Whenever  the  predicate  is  satisfied, 
the  method  is  invoked  The  bound  variables  to  the  logic  query  may  be  used  as  parameters  to  the  method 
An  example  of  a  demon  is  when  a  code  object  is  marked  as  "code  complete",  then  it  should  be  complied  A 
compile  demon  is  constructed  as  follows: 


( (code - obj  ect  ’j  status  cod* -complete)  )  =>  (compile  7x) 


The  compilf  method  is  applied  using  the  free  variable  “9x*  10  all  objects  satisfying  the  predicate  The 
assumption  is  that  thai  compile  method,  whether  it  is  successful  or  not  will  side-effect  the  slate  of  the  code 
object  to  some  stale  older  than  'code-complete  ‘  This  will  inhibit  continual  recompilation  of  the  object 

Slot  assertions  sirnilarily  make  use  of  the  query  mechanism  to  ensure  satisfaction  of  an  event  l  nine  demons 
assertions  are  intended  to  describe  logical  relationships  between  objects  Tne\  describe  a  set  of  values  that 
a  slot  is  to  contain  Whenever  an  object  is  modified  which  may  cnange  one  of  the  constraints  tfie  associated 
predicate  is  evaluated  to  determine  if  a  change  should  be  made  to  the  slot  value  A  principle  use  of  slot 
assertions  are  to  establish  inverse  relationships  between  objects  To  do  tms  *t  have  introduced  the 
construct  which  denoies  an  instance  of  th«  object  class  being  defined  For  example  a  project  object  must 
maintain  a  list  of  all  the  programmers  assigned  to  the  project  The  object  schema  fur  a  project  will  be 
defined  as 

(defobject  project 
(progranaer •  ’  (’x) 

assert  ( (programmer  ’x  current - proj *ct  •)))) 

The  third  use  of  Loghsp  is  to  construct  rules  about  the  object  base  These  are  predicates  that  use  the  facts 
already  asserted  For  example,  we  are  able  to  define  a  rule  stating  that  if  an  employee  is  not  assigned  to  a 
project  and  is  not  a  manager,  then  the  employee  is  unassigned 

(defrule  unaasignad 
( (unaasignad  7x) 

((employee  ?x  manager  false)  (employe*  7x  currant -pro j act  nil)))) 

Demons,  queries,  and  assertions  can  now  be  constructed  to  manipulate  unassigned  employees 

Our  initial  approach  tcTperforming  logic  queries  was  to  have  them  all  evaluated  on  the  centra)  server  machine 
This  permitted  us  to  get  a  functional  workstation  query  capability  without  having  to  distribute  the  LogLisp 
knowledge  base  across  the  network  A  new  approach  has  been  developed  to  get  Loghsp  to  directly  access 
the  distributed  object  base.  We  plan  to  do  this  by  making  an  object  schema  for  a  LogLisp  predicate  object 
LogLisp  internally  represents  predicates  as  a  Common  Lisp  defstruct  By  modifing  LogLisp  to  use  the 
predicate  object  rather  than  the  defstruct.  we  expect  to  be  able  to  allow  predicates  to  be  distributed 

LogLisp  clauses  are  represented  as  lists  where  the  functor  position  is  a  symbol  that  names  a  predicate  lr. 
LogLisp.  the  predicate  structure  is  placed  on  the  symbol  s  property  list  Since  the  onh  attribute  of  symbols 
that  we  distribute  across  the  network  is  the  symbol  name  we  will  implement  a  LogLisp  symbol  table  object 
containing  a  distributed  lookup  table  The  lookup  table  relates  symbols  with  predicate  objects  In  essence, 
we  will  merged  the  LogLisp  database  into  the  object  base 

3.1  The  Framework  Interface 


The  framework  interface  for  creating  object  schema  methods  rules  and  demons  is  defined  below  Brackets, 
braces,  stars,  plus  signs  and  vertical  bars  are  metasyntactic  marks  Brackets  and  indicate  that  what 
they  enclose  is  optional  (may  appear  tero  times  or  one  lime  in  that  place)  the  square  brackets  should  not 
be  written  in  code  Braces.  {  and  }  simply  group  what  they  enclose  and  may  be  followed  by  a  star  (*) 
indicating  that  what  the  braces  enclose  may  appear  sero  or  more  times  Within  braces  or  bracken,  a  vertical 
bar,  I.  separates  mutually  exclusive  choices 


m. 
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tlefobjert  (  objtct-name  (tinclude  {  luper-elatt)  *)i) 

{  !  liot  -  name  jiaiuc}  ,  ((ra/ue)*) 
type  object-name 
:assert  ((clause)*)  )}*) 

ilt  filri'ion  rule  •  no  rue  | method )  (|riau*e)*)j 

ilrfmeth  method-  name  (( argument  object-name )’  I  oryumenf* )  form') 
'iefrulr  rtii( •  name  ( j  clause!*  I*  I 


4  The  Inspector 


7  j;>p!a\  objects  in  the  knowledge  base  and  view  the  actions  being  p er ferried,  we  have  const : u.’..ed  a 

e*a:  .n;ra;  inspector  The  inspector  contains  four  windows  as  shown  in  figure  a  These  wind-  a?  .nc’ud.’  a 
.--•or.  window-  to  describe  the  object  hierarch'  in  the  knowledge-base  a  window  t  t.*b  ning  trie  ob;  -  i  $  •••> 
sr.C  s  ues  a  task  window  for  describing  the  demons  and  constraint?  being  app he-!  t .  the  knowledge- ’.ate. 
-.!  1  s  Lisp  Listener  window  The  user  interacts  with  the  graph  window  end  th*  r>  ”<.«  descnptioj  window 
;  •’\piore  the  contents  of  the  knowledge-base  As  operations  are  performed  on  the  knowledge-!  ase.  events 
ve  triggered  and  displayed  in  the  task  window  The  task  window  ic  for  display  purposes  only  *o  show  th  • 
v #■  r, t s  that  are  occuring  The  Lisp  Listener  window  is  used  to  run  method,  and  modify  the  knowledge  base 

7"  additional  capabilities  are  planned  which  include  a  mult  iprocess  inspector  er.J  a  natural  language  query 
fa-itdits  Within  any  single  user  workstation  the  programmer  performs  many  functions  often  in  p*/allei 
h- Tti-  of  these  functiors  compete  for  interaction  with  the  programmer  The  muluprocess  inspector  will 
. \phire  use:  interface  techniques  to  effectively  manage  the  screen  Particular!)  with  a  framework  that 
mains  rules  about  the  ordering  of  operations  and  when  operations  should  be  performed  many  operations 
may  be  initiated  by  the  framework  instead  of  being  explicitly  started  by  th*  programmer  The  user  interface 
snould  notify  the  programmer  of  the  pending  activities  and  allow-  him  to  easily  prioritize  and  select  which  task 
t ..  service  next  We  plan  to  implement  this  through  the  use  of  multiple  pop-up  windows  As  a  new  activity 
is  started  a  window  will  be  assigned  to  it.  When  the  window  exposes  itself  to  request  user  interaction,  the 
programmer  may  choose  to  service  the  request  ignore  it,  or  cancel  the  activity. 

The  natural  language  query  facility  will  explore  the  construction  of  an  intelligent  help  facility  Several  simple 
natural  language  parsers  are  available  to  translate  a  natural  language  request  into  a  logical  query.  VVe  intend 
t c*  integrate  su*h  a  system  into  the  framework  and  enable  users  to  explore  the  f r  ject  database  and  to  obtain 
help  on  the  use  of  the  system 


5  Future  Topics 

The  prototype  we  have  constructed  is  still  in  its  early  development  stages  Many  topics  remain  to  be 
investigat'd  We  have  already  discussed  some  of  the  deficiencies  in  the  system  and  our  plans  for  resolving 
them  In  addition  we  are  interested  in  addressing  several  additional  topics 

r».l  Transaction  Processing  and  Object  Locking 

,r  ar.y  multiple  user  database  the  ability  to  lock  objects  and  encapsulate  transaction'  is  necessary  for  data 
•  r.s:stene\  Due  to  the  centralized  implementation  of  the  data-base,  it  is  difficult  to  introduce  concepts 

f  irihr:  ions  Thm  i'  particularly  necessary  due  to  the  constraint  checking  performed  by  the  data  base 
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The  K.1SS/N  Knowledge-Base  Inspector 


When  a  series  of  opera!  ions  arc  applied  lc>  the  data  base  inconsistent  suite*  n  av  n  'i  ii~  •  ns 

nave  completed  The  data  base  must  not  attempt  to  correct  this  inconsistent  n  ’  :  ’  sartn  n  r 

complete 

Since  mult  iple  users  are  accessing  the  data  it  is  not  reasonable  i..  .1;  .Bin  nt'  <■  *  "  .  .  t  -•  tie  ■  •mM  • 
and  demons  A  single  transaction  ma>  run  for  a  significant  length  <>f  ur-  iur  ,:al  appr-  ..  :  his 
problem  is  to  use  object  locking.  Locked  objects  will  not  invoke  th<  com.',  ram.  evening  me,  1  ■  t • : - r:  «.h>", 
thev  are  modified  This  requires  the  user  to  lock  all  objects  that  riav  be  t<  m.t.iv  modified  it  <■  rs< 
of  a  transaction  The  locked  objects  will  not  be  available  t •,  an;,  other  users  i  •  -■  : > s t r n  1 ' ■  ■  v.  d  ,tc  red 
when  trie  obiects  are  unlocked 


5.2  Access  Control 

A*  with  ant  multiple  user  programming  environment  a  wide  variety  of  object*  and  reia'.ionshios  ,  visi  that 
must  be  protected  against  accidental  or  malicious  use  The  knowledge  base  must  be  able  tc  distinguish 
between  users  and  carefull>  control  the  ability  of  users  to  examine  and  mo  .’.it's  knowledge  bav  ejects 
Wood  SO 

Secure  information  processing  technologies,  particularity  in  dt^tribut-;!  v  'ten.'  are  -;>t  well  understood. 
Te-hniques  remain  to  be  developed  to  enable  reasonable  leve,«  of  data  security  to  be  mamtainec  wituout 
excessive  costs  both  in  development  of  the  secure  system,  and  its  resulting  per1',  m  ar.ee  We  do  m  :  .mended 
tc  address  these  issues  other  than  to  examine  minima!  levels  of  as*ociai mr,  between  users  anu  trie  objects 
they  are  responsible  for  and  the  ability  to  grant  and  deny  acres;  or:  t  os.1  obj>r!> 

f"  u'  ’urrent  approach  is  to  control  access  to  an  object  using  a  primitive  framewere  object  class  r'i'ej  .  ■•oi'c- 
tyi’  A  role  object  contains  three  .'lots  of  objects,  methods,  and  users  each  wit:,  a  logical  assertion  describing 
the  set  of  instances  that  fill  the  slots  When  a  method  is  applied  to  an  object  .rstance,  the  system  will  be 
searched  for  a  role  object  that  contains  slot  values  of  the  object  instance  the  method  being  applied,  and 
tne  user  making  the  request  The  principle  limiting  factor  of  ant  access  control  system  will  be  performance. 
The  approach  described  provides  a  high  degree  of  flexibility  and  granularity  Should  performance  become  a 
limiting  factor,  we  pian  to  scale  back  some  of  this  functionality'  in  favo"  of  reasonable  execution  speed 

5.3  Configuration  Management 

W  ithtn  any  software  development  environment,  the  h 'Story  of  prev  on-  cperaticns  and  instanc-*  of  objects 
mus:  tie  maintained  In  order  to  retain  such  a  compete  history  for  bn  kl-ackmg  to  a  previous  decision  or 
rep'ioyinp  the  soft  w  are  development  activity  ,  each  modification  to  an  obje'i  j-i  be  maintained 

To  manage  the  se;  of  changes  to  a  baseline  object  objects  are  chained  together  .o  ordered  lists  along  special 
■eiat  mnships  These  relationships  are  historv-of  alternativp-of  part-of  and  version-of  The  history* 
of  relationship  links  all  object  instances  that  have  brer,  modified  from  a  baseline  object  When  an  instance 
is  n  d:fied.  instead  of  changing  slot  values  a  new  instance  will  be  created  and  linked  to  the  baseline  object 

Trie  alternative- of  re  lationshifi  is  distinct  from  the  history-of  reiauonshij  in  that  it  ident  i  fir*  at  un ordered 
list  of  objects  This  permits  the  different  alternative  objects  to  be  manipulated  b>  multiple  developer*  and 
;er~',i:s  object  histories  to  fork  into  different  paths 

r,r  a-"  aggregated  using  the  part-of  relationship  W  hen  a  new  alternative  of  »r,  <>i.j**t  i*  created 

o  »'!*  or  which  the  modified  object  is  a  part  must  ai'-o  be  changed  This  will  cause  a  ^as^ading  of  »'» 
t.t  >  rr  at  iv  »*  u.  be  created  by  follow  ing  the  inv  erse  part-of  relationship 

’  version -of  relationship  i*  lik>  alternntivr-ofhowevern  is  used  to  mark  a  history  i  lenient  o'  an  ,  >|>ie.-t 
a-  tie; i, g  c. iini  let ed  or  ready  to  release  \  ersion*  will  form  an  ordered  lisl  and  (  herefoee  must  be  sv  n  hr,  >n  ized 


among  the  multiple  developers  As  with  the  alternativc-of  relationship  a  new  version  results  in  propagating 
versions  up  the  hierarchv 


Figure  2:  Configuration  Management  Relationships 


An  example  of  each  of  these  capabilities  is  shown  in  figure  2  depicting  a  hypothetical  compiler  project.  A 
compiler,  targeted  for  the  XYZ  machine,  is  designed  and  its  implementation  started  As  the  code  for  the 
compiler  is  written,  modifications  are  made  to  it  resulting  in  new  copies  of  the  object  linked  through  the 
history-of  relationship  As  the  first  release  of  the  compiler  approaches,  it  is  decided  to  also  generate  code 
for  the  ABC  machine  An  alternative  to  the  current  code  generator  is  created  and  is  associated  with  the 
alternative-of  relationship.  Parallel  developments  are  now  in  progress  on  code  generators  for  both  the  XYZ 
and  the  ABC  machines  Finally,  the  first  release  of  the  XYZ  and  ABC  compilers  result  in  the  most  recent 
history  elements  being  placed  in  the  version  list  using  the  versioo-of  relationship. 
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Inference  Processes  in  the  KBRA 


Andrew  J.  Czmhry,  Jr. 
Sanders.  A  Lockheed  Company 
95  Canal  Street 
Nashua,  NH  03061 


Abstract 


Them  arc  inference  processes  which  are  supported  within  Sanders'  prototype  of  an 

intelligent  assistant  for  requirements  acquisition  !  and  analysis,  the  Knowledge-Based  Re¬ 
quirements  Assistant  (KBRA)  •  These  processes  are  unified  in  SOCLE  \  the  underlying 
knowledge  representation  language  in  KBRA.  The  inference  processes  are  the  following: 
inheritance,  automatic  classification,  dependency  tracing,  local  propagation,  truth  mainte¬ 
nance.  contradiction  detection,  default  reasoning,  reasonable  value  checks,  and  associative 
retrieval.  These  inference  processes,  combined  with  application  knowledge,  are  whar  pro¬ 
duce  the  ‘■intelligent"  behavior  of  this  assistant.  More  specifically,  they  provide  active 
support  for  the  incremental  formalization  of  requirements.  Addilionaliv.  they  support  the 
following  activities  representative  of  the  processes  associated  with  incremental  formaliza¬ 
tion:  reuse  of  community  knowledge,  multiple  viewpoints,  critiquing,  analysis  validation, 
and  explanation. 

The  intent  of  thr  report  is  to  explain  how  a  variety  of  artificial  intelligence  (AI)  inference 
techniques  have  been  used  in  the  context  of  the  KBRA  and  the  resulting  “intelligent" 
behavior  of  the  KBRA  system.  In  so  doing,  it  will  indicate  the  inference  processes  we  have 
used  and  how  they  support  requirement  characterization.  (By  requirements  characteriza¬ 
tion  I  mean  the  acquisition  and  analysis  of  requirements;  the  declaration  of  ideas  and  the 
analysis  and  engineering  of  the  interaction  of  these  ideas  as  they  are  fit  into  a  evolving 
model  of  a  system  to  be  built.)  Additionally,  particularly  interesting  examples  of  the  man¬ 
ner  in  which  inferences  support  the  various  characteristics  of  requirements  characterization 
will  be  presented. 

1  Acqnisit ion  if  requirement?,  a?  used  here,  nwn?  die  declaration  of  idea--  and  i  hen  plammui'  v.  t* . 
some  model  or  model.-  of  the  system  to  Le  buds 

•This  work  li.i«  been  funded  by  the  Rome  Air  Development  Center  Ciiffis*  An  Four  bo-e  m  N'-u  Vuk 
under  Contrail  N . • .  F30G02-8VC-02G7 

'SOCLE,  a  homonym  derived  from  Structuied  Object  and  C  onstraint  1. alienage  Environment .  Ham-  - 
a  hybrid  system  with  FRL  jRobert?  and  Goldstein;  and  Constraint-based  Language?  Steele  a«  nm-Mois 
It  support?  both  obiert-oriented  and  constraint-based  programming  style? 
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1.  Introduction 


The  current  KBRA  prototype  is  a  demonstration  of  many  of  the  essential  fea’ures  of  t he  ul¬ 
timate  Knowledge-Based  Software  Assistant  (KBS A)  [Green,  Luckham,  Baizei .  Cheat  ham 
Rich  requirements  assistant.  It  is  designed  to  support  the  requirements  engineer  beginning 
at  the  initial  phase  of  requirements  work  and  continuing  through  to  document  preparation 
In  using  KBRA,  an  engineer  makes  the  commitment  to  working  on-line  not  on  paper  The 
reward  for  this  commitment  is  that  the  decisions  made  and  their  associated  justifications 
are  not  lost,  but  rather  become  part  of  the  KBS  A  environment  f.c  be  available  and  used 
throughout  the  entire  software  life  cycle. 

In  order  to  achieve  the  goal  of  helping  automate  and  mediate  requirement  -  characterization , 
several  inference  processes  have  been  incorporated  into  KBRA.  The  inference  .roc  asses  arc 
listed  in  figure  la.  These  inference  processes,  combined  with  application  knowledge,  are 
what  produce  the  “intelligent”  behavior  of  this  assistant  More  spocifica'lv,  they  provide 
active  support  for  requirements  characterization  (see  figure  lb).  Although  this  list  is 
not  exhaustive,  it  does  cover  the  representative  qualities  of  requirements  characterization. 
The  following  matrix  (figure  Ic)  highlights  the  inference  processes  within  KBRA  and  .lie 
requirements  characterization  qualities  which  they  support. 

inheritance 

automatic  classification 
dependency  tracing 
local  propagation 
truth  maintenance 
contradiction  detection 
default  reasoning 
reasonable  value  checks 
associative  retrieval 

Figure  la:  The  Inference  Processes 

incremental  formalization 
reuse  of  community  knowledge 
multiple  viewpoints 
critiquing 
analysis  validation 
explanation 

Figure  I i)  A  Partial  List  of  Requirements  Characterization  Qualities 
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Figure  lc:  Inference  Processes  and  the  Requirements  Acquisition  and  Analysis 

Characteristics  they  Support 


The  intent  of  this  matrix  is  to  serve  as  a  summary  of  the  relationships  between  the  processes 
and  the  characteristics.  It  is  not  necessarily  a  reference  for  the  following  report  sections. 

This  report  will  initially  define  incremental  formalization  and  the  representatives  of  its 
associated  requirements  characterization  qualities  used  in  this  matrix.  Subsequently,  it 
will  justify  the  y7  s  in  the  matrix,  each  of  which  indicates  that  the  respective  inference  pro¬ 
cess  is  used  to  support  the  indicated  characteristic.  Additionally,  particularly  interesting 
examples  (indicated  by  boxes  with  *s  in  them)  of  the  manner  in  which  inferences  support 
the  various  characteristics  of  requirements  acquisition  and  analysis  will  be  presented.  As 
you  will  note,  although  these  inference  processes  are  called  out  separately,  they  actually 
are  used  in  conjunction  with  each  other.  This  intertwinement  approach  is  no  accident. 
The  processes  act  as  cooperating  agents  and  produce  synergistic  results.  The  results  can 
be  seen  in  the  “intelligent"  behavior  within  KBRA. 

2.  Incremental  Formalization  and  Requirements  Characterization 

Requirements  characterization  is  the  declaration  of  ideas  and  the  analysis  and  engineering 
of  the  interaction  of  these  ideas  as  they  are  fit  into  an  evolving  model  of  a  system  to  be 
built.  The  following  sections  will  define  the  qualities  of  requirements  characterization  as 
listed  in  figure  lb.  The  goal  of  this  report  is  no'  to  justify  the  inclusion  of  these  particular 
processes.  This  information  is  listed  and  defined  here  to  demonstrate  the  usage  of  the 
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inference  processes  in  KBRA.  Supporting  arguments  for  the  belief  in  th<  -.ipoi  uu,-  e  n! 
these  qualities  of  requirements  characterizations  are  presented  elsewhere  ;  Raize:  t  loldman 
Wile  .  Czuchry,  Harris),  (D'Addamio). 

2.1.  Incremental  Formalization 

Incremental  formalization  refers  to  the  ability  to  capture  information  which  is  initially 
specified  informally  and  to  subsequently  evolve  that  information  step-by-step  into  a  more 
formal  specification.  An  example  is  the  formalization  which  begins  with  an  initial  use  of 
cryptic  notes  and  abbreviations  for  a  description.  In  an  effort  to  extend  general  compre¬ 
hensibility.  an  engineer  may  extend,  augment,  or  clarify  the  information  contained  in  an 
initial  outline.  In  order  to  do  this,  a  formal  investigation  of  the  information  contained  in 
the  outline  (e.g.,  functional  flow  analysis)  may  be  initiated.  As  a  result  of  formal  analysis, 
the  initially  informal  information  becomes  more  formalized  This  forma", zation  may  pro¬ 
ceed  automatically  in  some  cases  but  most  often  will  be  accomplished  a«  KBRA  supports 
the  engineer  in  performing  formal  analyses. 

2.2.  Reuse  of  Community  Knowledge 

Reusability,  as  used  in  this  report,  is  the  reuse  of  previously  defined  systems  and  their 
generalizations.  It  is  not  limited  to  the  specification  of  reusable  systems.  This  extension 
is  important  because  we  want  to  be  able  to  modify,  or  at  least  refer  to,  systems  which  are 
not  specifically  designed  to  be  reusable.  It  is  supported  in  KBRA  because  engineers  do 
this  naturally  when  characterizing  requirements. 

2.3.  Multiple  Viewpoints 

There  are  many  ways  to  look  at  complex  situations  when  frying  to  get  a  handle  on  a  prob¬ 
lem.  The  provision  of  multiple  viewpoints  within  a  system  are  more  than  a  mere  interface 
issue.  It  goes  beyond  the  manifestation  of  views  on  the  screen  to  actually  addressing  the 
needs  and  the  processes  of  problem  conceptualization,  definition,  and  analysis.  The  types 
of  perspectives  one  understands  (e.g.,  data  flow,  SADT,  R-Nets),  when  perspectives  are 
appropriately  taken  (e.g.,  establish  data  and  functions  before  the  actual  data  flow),  the 
types  of  information  processed  (e.g.,  states,  data,  software,  hardware),  and  the  breadth 
of  the  characteristics  of  information  (e.g.,  concurrency,  states  only,  “black  box”)  are  all 
factors  in  determining  how  one  looks  at  a  problem.  Since  different  viewpoints  of  the  same 
information  are  appropriate  at  different  times  and  for  different  people,  multiple  viewpoint" 
provided  essentia)  problem-solving  elements. 
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2.4.  Critiquing 

Critiquing  is  the  process  of  making  indications  and  contraindications.  The  goal  is  to 
make  an  analyst  aware  of  the  interrelationship  of  requirements  within  the  current  sxsteui. 
comparisons  with  other  similar  systems  (if  they  exist),  the  “laws”  of  nature,  and  possible 
contradictions  with  known  technology  limits. 
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2.5.  Analysis/Validation 


Analysis /Validation  includes  ensuring  that  the  requirements  which  have  been  specified  are 
actually  those  intended  (e.g.,  the  data  flow  meets  *he  processing  needs)  as  well  as  resolving 
the  requirement  parameters  bounding  the  problem  (e.g.,  the  optimum  size  of  memory  given 
cost,  physical  size,  response  time,  and  program  si/e  requirements). 

2.6.  Explanation 

Explanations  answer  the  question  “Why?” .  They  are  used  to  help  in  requirement  validation 
by  indicating  requirements  traceability:  1.  how  requirements  are  related,  and  2.  how 
requirements  are  derived. 


3.  Inference  Processes  within  KBRA 


In  order  to  achieve  the  goal  of  helping  automate  and  mediate  requirements  characterization, 
several  inference  processes  have  been  incorporated  into  KBRA  (see  figure  la).  These 
inference  processes  will  be  described  in  the  following  sections.  In  so  doing,  particularh 
interesting  examples  of  the  manner  in  which  inferences  support  the  various  characteristics 
of  requirements  acquisition  and  analysis,  cited  in  the  preceding  section,  will  be  presented. 
Although  these  inference  processes  are  called  out  separately,  they  actually  are  used  in 
conjunction  w  ith  each  other.  This  intertwinement  approach  is  no  accident.  The  processes 
act  as  cooperating  agents  and  produce  synergistic  results.  The  results  can  be  seen  in  the 
“intelligent"  behavior  within  KBRA. 

3.1.  Inheritance 

Incremental  formalization  takes  advantage  of  inheritance.  As  requirements  become  more 
formalized,  (e.g.,  an  uninterpreted  requirement  jin  KBRA  the  most  informal  type  of  a 
requirement!  becomes  an  activity;  data  becomes  geometric  data)  information  in  addition 
to  that  which  is  explicitly  specified  is  inferred.  An  example  of  such  additional  information  is 
an  expectation  about  data  within  an  activity,  whereas  no  such  expectation  could  be  created 
for  an  uninterpreted  requirement  since  the  uninterpreted  requirement  may  itself  turn  out  to 
refer  to  data  flow  rather  than  an  activity.  Inheritance  is  used  to  retrieve  expectations  and 
properties  of  objects  as  then  become  more  formalized.  Figure  2  indicates  the  expectation- 
associated  with  activities  and  the  lack  of  expectations  for  uninterpreted  requirements.  \ 
component  of  formalization  thus  becomes  the  determination  of  the  taxonomic  relation 
(class  relation)  of  requirements  within  the  general  hierarchy  of  requirements  know  ledge. 
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Figure  2:  Inheritance  and  Expectations  within  Requirements  Knowledge 
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Figure  3:  Class  Frames  for  a  Tracker  used  in  an  Air  Traffic  Control  System. 


Inheritance  can  also  be  exploited  in  addressing  reusability.  Class  frames 1  (‘generic  frames  ! 
can  be  used  to  represent  the  generalizations  of  concepts.  These  generic  frames’,  and  t  Ini'- 
generalizations  for  solutions  to  requirements  problems,  are  available  in  a  library  created  h\ 
knowledge  engineers.  1  An  example  is  presented  in  figure  3.  Reusability  becomes  a  matter 

*Class  framer  may  be  thought  of  a?  active  template#  of  distinguishing  features  and  properties  of  the  class 
its  members,  and  its  subclasses 

^Inheritance  facilitates  knowledge  engineering  because  it  allows  concentration  on  the  details  of  what  make4 
each  class  different  since  only  that  distinguishing  information  needs  to  be  explicitly  recorded  The  rest  cf 
the  characteristics  can  be  inferred  (inherited)  from  superclasses 
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of  instantiation  of  the  generic  frames.  Strcc  i.-vrv c  »•«.  .  '•r.ntu/1  i •  * , j> : •  ops,  constraints, 
relationships,  and  structure,  instamiali  m  results  in  »  !  jil-bodk-':  coiv.rpt  (see  figure  31 
which  forms  the  foundation  for  reuse 

Inheritance  is  used  within  the  presentations  v  ! : i r ; r  ciea'e  Multiple  '  icwpoints.  The  infor¬ 
mation  that  is  presented  in  a  Review  preset, ’a;  on  vara  s  d  mordent  upon  the  classification 
of  a  requirements  entity.  For  example,  tin  i ,-c-s  and  rev  it: tiers  of  data  items  are 
presented  while  the  subfunctions,  data,  and  -  .  ■  ar-1  or.  .meet  ten  activities. 


Critiquing  takes  advantage  of  inheritance  in  ••  --r.fi  ■  ut  nimnci  It  uses  inheritance 

to  compare  tne  requirements  as  defined  b»  •  ~  Mirn^er  wp  •*.  generalizations  lor  known 
components  and  systems  s'ored  within  ti.i  <  "uo  ’.nii'  cno'vie^ce  drd  a  base  (application 
knowledge  modules).  Through  tie  act  of  spec  >  mg  a  '-’•r-Tem  to  defined  as  an  Air  Traffic 
Control  System  (A Tv  •.  comparisons  .sucii  ,i.-,  i h< dos<  ribed  below)  are  made  between 
the  generic  frame  for  A  I  Cs  (and  its  components ]  and  the  system  which  the  engineer  is 
defining.  This  j*  usee  to  suggest  possible  inroiisgd*  n  ics  or  incompleteness. 

For  example,  a  g-mcric  tracker  is  depicted  in  figure  4a.  Since  this  tracker  appears  in 
the  community  knowledge  of  th»-  ATC  application  knowledge  module,  it  can  be  used  t<u 
comparison  to  anv  tracker  specified  fry  an  engineer  (e.g..  figure  4hl.  KBR  A  <  an  crit  ique  t  fi* 
tracker  requirements  and  give  the  engineer  the  following  feedback:  “Most  tracker'-  have  a 
Terminate-Trark  requirement,  but  you  seem  to  he  missing  one."  This  critique  is  the  resuli 
of  a  comparison  between  the  expected  subfnmtinn  tvpev  on  the  ■  bos  fi.mie  and  the  t\p< 
of  the  actual  subfu:  etion.-  for  the  new  tracker 
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Figure  4b:  A  Tracker  being  specified  while  establishing  the  requirements  for  an  ATC 


3.2.  Automatic  Classification 


Automatic  classification  is  the  process  by  which  objects  are  automatically  placed  in  the 
most  specialized  class,  within  the  requirements  knowledge  hierarchy,  consistent  with  what 
is  known  about  an  object.  This  is  important  because  specialized  classes  contain  more 
detail  and  expectations  than  their  superclasses.  As  a  result,  additional  information  can 
be  deduced  (through  inheritance  as  mentioned  earlier)  when  classification  takes  place 
Although  KBRA  does  not  have  a  general  purpose  classifier,  application  specific  automatic 
classification  is  supported.  The  classification  proceeds  using  special  purpose  classification 
decision  trees  which  exist  in  KBRA  application  knowledge  modules. 


Automatic  classification  takes  place  throughout  the  incremental  formalization  process.  For 
example,  when  a  source  or  sink  requirement  entity  is  added  to  a  datum,  that  requirement 
entity  (which  may  have  been  uninterpreted  up  to  this  point)  is  automatically  classified  as 
an  activity. 


Automatic  classifications  also  play  a  role  when  components  are  reused.  The  following  i- 
an  example.  Upon  indication  of  a  tracker  as  a  component  of  an  Air  Traffic  Control  Mstem 
(ATC),  KBRA  will  classify  the  tracker  to  the  best  of  its  ability  using  the  decision  tree- 
cached  on  the  generic  tracker  frame.  It  currently  knows  about  several  different  types  of 
trackers  (e.g.,  kalman  filter,  alpha-beta,  alpha-beta-gamma,  multiple  hypothesis)  each  o) 
which  have  different  distinguishing  characteristics.  If  there  is  a  need  for  a  high  degree  of 
accuracy  and  reliability  and  not  a  stringent  requirement  on  processing  time,  the  system 
will  classify  the  tracker  as  a  kalman  filter.  Since  related  requirements  imply  certain  other 
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requirements  (in  the  situation  indicated  above,  a  kalman  filter  ;«=  ac!  r.:  1  j- 

othei  requirements),  it  is  important  to  have  the  system  an  tom?'  rah'.  '  '  h'"-‘ 

implications  and  take  them  into  account  when  requirement.-  are  <•  ,  t-"‘  u  in  •  ddim 
to  recognizing  implied  requirements  by  successful  automate  <  mssi’icvio  *.  the  feasq-u-  , 
of  related  requirements  are  checked.  In  cases  where  classification  u  >:ot  -o-sible  |e  g  high 
accuracy,  high  reliability,  fast  processing  time),  requirements  inc  i  siste  tt  with  .  umuv. 
technology  are  recognized. 

3.3.  Dependency  Tracing 

Dependency  tracing  is  fundamental  to  the  KBRA.  It  forms  the  foundation  for  several  infer¬ 
ence  processes:  local  propagation,  truth  maintenance,  and  contradiction  detection  Each 
of  these  processes  trace  dependencies  in  order  to  perform  their  inferences.  Addifonaliy . 
dependency  tracing  supports  requirements  characterization  independer fly  ol  tnese  o lie- 
inference  processes. 

It  plays  a  role  in  helping  support  the  formalizat  ion  c<  requirements,  pres*  nting  requirements 
from  many  viewpoints,  critiquing  choices,  analyzing  and  validating  specifications,  and 
explanations.  Of  all  of  these,  it  is  especially  important  for  expianMirns.  The  “why 3'  of 
requirements  are  associated  with  dependency  links  v  hich  must  be  traversed.  The  goa  l  ci 
this  traversal  is  to  ascertain  the  premises  from  which  the  requirement  has  been  derived  and 
the  relations  between  those  premises  and  the  requirement  in  question.  The  search  space  of 
requirements  entities  is  managed  by  searching  among  only  those  entities  with  dependency 
relations.  This  addresses  the  needs  which  occur  during  requirement  traceability. 

An  example  of  dependency  tracing  is  the  ability  to  trace  “because’*  relations.  A  certain 
requirement  for  processing  time  may  be  set  “because”  there  is  a  requirement  for  near-real- 
time  performance.  As  long  as  the  requirement  for  pear- real- time  performance  is  valid,  the 
processing  time  will  persist.  If  the  requirement  for  near-real-time  performance  is  retracted, 
however,  there  may  no  longer  be  any  support  for  the  processing  time.  If  this  is  the  rase, 
the  processing  time  will  be  retracted.  (A  default  processing  time  wilt  be  reassert'd,  if 
possible,  through  default  reasoning.) 

3.4.  Local  Propagation 

There  are  two  classes  of  local  propagation:  1.  daemons  or  procedural  aftarhm*>r ;•  md  J 
ronstraint  propagation. 

An  example  of  local  propagation  using  procedural  attachments  is  the  comnlet n>;  -i.ir' ;  « 
descriptions  (an  automated  part  of  incremental  formalization).  When  requin  *s 1  >'  t.ev 
activities  are  stated,  default  data  may  exist  (see  default  reasoning,  sett  ion  ”  "1  h«>  1 

may  lie  some  way  to  “wire-up”  this  dangling  data  (e.g..  existing  solely  as  input  '<  ‘In  t  • 
activity!  to  other  data  which  is  already  present  in  the  system  (e.g.,  the  output  ,  .t  an<>'h*  : 
activity).  The  use  of  the  X  and  Y  values  from  a  stereographic  projection  of  a  radar  return 


could  be  used  as  the  loca'i  •>».  '  •  >  a  •-aGe-  TL  •  .re.-  •  po.-eds  automatical!* 

by  triggering  the  procedural  a",  i.  t: i«- ■  '  •••;<».•«•:  n  at  •  :i  ..»*• 

An  example  of  constant  promt.  aMi  o  <><  <  ■  ,•  -o.  .  ‘  it:  :  C mu •  < e  Mo  specification 

of  an  equation  relating  req>nrf!i:t-'  •  -  '  .  :  ‘  •  ••  •  >u  -xamp-*-  y"..pag;  :t  im.  occurs 

due  to  the  declaration  of  .1  sin  pi.  •;«  -  .  •  n.Mr.uia  -r  an  air  traffic  control 

system.  The  context  of  this  L-mi  be  :  ■  •  :  .  *.a 


A  •  1  f  \ 


Figure  5a.  Propagation  of  Values  wiflrr.  the  Structures -Object  Decomposition  for  the 
AIR  TRAFFIC  CON  FROL  >Y?TFM  Concept 

This  Figure  shows  a  partial  decomposition  of  the  AIR  TRAFFIC  CONTROL  SYSTEM  us¬ 
ing  "input-from”  "tracker',  “objects-tracked” .  a-d  geographic-coverage”  slots.  The  slot 
fillers  for  each  of  these  parts  are  LONG-RANGE-R ADAR.  ALPHA- BETA-TRACKER. 
COMMERCIAL-AIRCR  At  T.  and  CR ITICAL  ARE  A  respective!v.  Each  of  these  is  a 
structured  object  which  (as  not  1  in  the  section  on  inheritance)  inherits  values,  defaults, 
and  procedural  attachments  from  generalized  concepts 

In  such  a  decomposition,  slots  which  are  related  through  formulas  mat  be  functionally  far 
apart.  For  example,  the  distance  that  an  aircraft  car,  caver  before  a  »rack  is  established 
is  related  to  the  speed  of  the  .Fit  raft .  sweep  rate  V  :  he  racRi  an<<  number  of  him 
required  for  the  tracker  to  establish  a  new  track.  Letiing 

R  -  the  sweep  rate  of  the  system  r.i'iar 

N  —  number  of  radar  returns  required  to  ■  -m  i . ! > s \  )■; 

T  =  initiation  time  for  establishing  a  tea  k 
S  -  speed  of  a  commercial  aircraft 

D  —  distance  covered  by  the  aim  aft  i-c  *ore  a  track  ;  .•  •  ,.n  d 


Hf  can  quickly  establish  the  formulas: 


R  *  N  -  T 
T  *  S  =  D. 

The«e  formulas  are  illustrated  on  the  diagram  as  wiring  networks  When  vaine«  are  =oi 
for  "<w  eep-rate” ,  “number-of-radar-returns-required" .  and  “speed"  as  shown  ;)2  sec 
600  knots  respectively),  then  values  of  1  minute  (60  sec),  and  10  nau’ical  miles  are  auto 
ma,irall\  propagated  to  the  “initiation-time”  and  “distance”  vanabi.  >.  and  need  l.< 
entered  as  independent  requirements. 

These  equations  propagate  values  in  a  bi-directional  manner,  rigu--  -l  depict*  the  're 
er«e"  propagation  Values  are  set  for  the  “sweep-rate",  “speed'  .  and  'duo  a  u.-*-"  (',2  ?« c . 
oop  knots,  and  10  nautical  miles  respectively)  The  calculated  value'-  f.  and  1  minute  (60 
=e-  appear  for  the  “number-of-radar-returns”  and  “initiation- 1  ime”  respectively. 


Figure -!>b:  “Reverse”  Constraint  Propagation 
3.'».  Truth  Maintenance 

I  ru'  i.  maintenance  supports  changing  your  mind  Changing  tour  mi  ml  <  nui<i  >>■  <  u-  •  'im'ii: 1 
or’  incremental  formalization,  reuse,  or  analysis  validation.  Trut  h  maintenam  <  in  KRH  \ 
;s  realized  through  constraint  maintenance  and  constraint  propagation. 
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Figure  6b:  Constraint  Maintenance  upon  the  Retraction  of  a  Structured-Object 
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Figure  6c  Constraint  Maintenance  upon  the  Assertion  of  a  Structured-Object  Slot  Fill*  ! 
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3.6.  Contradiction  Detection 

Contradiction  d*-t<  ct 'on  pro-  :  J-s  feed'  :n  r.  \vh«*.i  .  •  - 1  ^jic a't  •.  •’  'rmmeo  I  hese 

inconsistencies  could  :»**  m  th*  term  oi  irrormat  ibl*  •  a»u*  >•  ?.*••;  rend  <*:•  .g..  a  •  ase  w  here- 

X  implies  not  Y.  X  i-  true.  1>  is  1  ru«*  I  •  : .  *  :m->  ;r’.  nu,:  ;  : •  ,  ■  m:'  ... :i a  1  resolution  or 
in  the  form  of  type  error*  (e.g  .  using  V.'  i  D  !  i'\  -is  t"  1  mt> •  .•’•*. t~er  A'  TIN  I T  X 

ionly  DATA  can  be  an  input  u  out  ■  ;*  -.Id  ■  om  often  ai  ::?r  in  a  vane*  >  •••’  <mcun:«tanres 
They  arise  as  information  is  K-Mtiaiiied.  When  this  hapr  us.  ‘e<~dr  ack  must  be  given  so 
that  compatible  requirements  may  h  ■  spec i. bed  throughout  each  <  mnpo.et.t  of  tm  sys.em 
Analysis  'Validation  is  partially  an  attempt  to  resolve  numeric,  completer.''?*.  and  type 
expectation  contradictions.  T n«.*  use  of  contradiction  do -e*' lion  in  'he  reuse  of  community 
knowledge  and  in  critiquing  w ■ ! >  be  discussed  ir  great*-1:  detail 

Contradiction  detect. -mu  :s  important  for  reusable  components  because  i;  traps  conditions 
when  a  con.po  .e».t  should  NOT  be  reused  Examples  of  such  condition.?  are  as  follows •  1. 
magnitude  discrepancies  I**  g  .  response  time  of  6  sec  i«  possible  ns  .  :,  a  certain  display, 
but  a  response  time  of  O.b  sec  is  required  in  this  ra.«e  a  displa.  w  u  \  i|,c  appropriati 
response  time  should  he  rhos  r  ).  2.  type  inconsistencn-r  (*  g  e  :*.  compound  expects  a 
location  as  polar  coordinate:-  for  an  input,  but  the  input  v  ;i,  be  X.Y  *  nominates,  in  this 
case,  a  different  component  chc  aid  be  used:  one  that  ex  pec  is  X.Y  r  oord  inm  ec  i . 

It  is  especially  critical  in  critiquing.  If  possible.  KBR A  will  automatically  resolve  the 
inconsistency  based  on  the  level  of  support  indicated  tor  t  j>*»  requiremt  n,is  involved  The 
declaration  of  a  levei  of  support  is  available  to  the  user.  Included  are  default  (use  only  when 
nothing  else  is  available),  supposition  (try  out  a  possibi value*.  r*e|iet  fth;«  value  is  very 
probable),  and  constant  (reserved  for  definite  constants  e.g..  r  i.  Toe  most  tentative  level 
of  support  among  the  inconsistent  values  is  automatically  tetractec.  if  more  than  one  value 
has  the  same  level  of  support,  the  user  is  prompted  to  make  a  selection  A*  an  example,  let 
us  return  to  the  AIR  TRAFFIC  CONTROL  SN  STEM.  Tht  'clues  •  e-d  in  figure  7a 
are  all  consistent.  However,  if  there  is  a  requirement  that  flu  c; itical  area  be  10  nautical 
miles,  timt*  a  contradiction  a.  ill  arise  p=e<-  figu-c  ?b',  Our*  n[  ‘i*«*  'equipments  that  has 
been  explicitly  set  f  “swt er.-rate" .  “number-of-rada:-- .  urnr  .  Voet .  Mistanc e"  i  mis' 
be  retracted. 

If  there  were  only  opt  so  at  the  lowest  lev*  *  -  f  *-,*;; pr: :  e.g  *” i . um * '»- r -■  -  -s  v <■ : 

returns"  were  a  supposition  while  the  others  wore  I'l'oc  : .  i'  >.«.c*ui«.  •>..  retracted.  ho-'*  \ 
in  the  example  depicted  :n  figure  >  b.  the  ' wp-ra'e  mtr.i.  .  ■  -moat-:*  ’  ..  m-  a  p 
“distance"  have  been  enter'd  as  suppositions.  v\b,'e  the  ".  pvd  ft-.*-  been  r :iter<'«l  a-  a 
belief.  Since  it  ?s  riot  possible  to  automatically  re-'-R-*  ;  pr  .  ,  , ?  j-.~  :*.r t  ,.*>.*•  Hu  rt  »r*  ‘ 
premises  at  the  weakest  support  level;,  the  user  ••  id  :>  prom  -d  o  o  ,*.!•:<  h*  r*»« '‘ut  ■ 
KBRA  will  he  ip  form  attention  on  the  appropriate  r  hot*  '**  b\  •  n:  •  :.  '  n  *  '!•  |»  *i  ntst ■- 
with,  t  he  lowest  level  of  support .  in  this  <  xamph*  the  support  *ons  '  v<  **p-r«i  .  '  .vtniU  i-oi- 
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radar-returns”,  and  “distance”.  Note  that  the  belief  “speed”  is  not  presented  lor  retraction. 
If  the  user  chooses  to  retract  the  “number-of-radar-returns” .  or  if  it  were  automatically 
retracted  because  it  was  the  only  premise  at  the  weakest  support  level,  then  a  value 
consistent  with  all  the  other  premises  will  be  propagated  to  it  (value  5  in  figure  7c) . 


Figure  7a:  Consistent  Premises 


Figure  7b:  Contradictory  Premises 
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Figure  7c:  A  New  Set  of  Consistent  Premises 

3.7.  Default  Reasoning 

Default  reasoning  is  an  important  issue  -Reiter:  For  us.  it  encompasses:  1.  the  existence 
of  default  values,  and  2.  the  persistence  of  default  values  (they  can  be  overridden,  but 
reassert  themselves  when  the  overriding  values  are  retracted:  This  type  of  reasoning  is 
used  in  all  aspects  of  the  KBRA.  When  nothing  rise  is  known,  this  reasoning  is  used  to 
determine  a  plausible  response,  characteristic,  or  value. 

An  example  of  this  occurs  in  reusable  components.  For  most  act  ivitb-.-.  there  is  an  expec¬ 
tation  of  data  flow.  In  the  specific  case  o!  a  tracker,  a  location  input  is  expected.  Location 
thus  appears  as  a  default  input  for  a  tracker.  I>y  incorporating  the  t "acker  into  a  system 
which  processes  radar  returns  to  compute  ret  tenges lat  coordinate*  •<  ,g..  r.tereog'Mphic  pro¬ 
jection).  the  actual  inputs  to  the  tracker  would  be  tin-  X  and  Y  values  ra’he-  i.  au  on, 
“location".  The  location  input  would  thus  bow  -vp  <ind  the  \  ir.put-  w o>  id  b<  \ 
and  V  values.  If  the  coordinate  conversion  of  tin-  .  ra;  s.er  rem*".  d  1 :  i  aete.T  „•  snip, 
point  in  the  future,  the  default  expectation  of  a  location  datum  m nut  into  '!'■  Macj-s 
would  be  reasserted.  The  internal  represent  a?  ion  •>:  m-  is  lepu-ted  :  r:  f:g  re  v-„.  !  r 
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Figure  8a:  A  Function  with  Default  Tracker  Input  of  Location 
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Figure  8b:  A  Function  with  Default  Input  Overridden 
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Figure  8c:  A  Function  with  the  Default  Input  Reasserted 

3.8.  Reasonable  Value  Checks 

Most  object-oriented  systems  contain  a  provision  for  reasonable  value  checks.  It  is.  there¬ 
fore,  not  revolutionary  that  we  take  advantage  of  this  in  KBRA.  However,  it  is  important  to 
indicate  the  wide  range  of  reasonable  values  that  can  be  specified  in  this  system  Predicates 
can  be  attached  to  slots  of  frames.  When  values  are  entered,  the  associated  reasonable 
value  predicates  are  evaluated  to  determine  if  the  value  is  reasonable.  cince  such  predicates 
can  be  any  Lisp  form,  a  wide  spectrum  of  reasonability  testing  is  supported. 

We  take  particular  advantage  of  reasonable  value  (.necks  in  incremental  formalization, 
critiquing,  and  analysis  'validation.  They  are  used  in  incremental  formalization  to  indicate 
reasonable  manners  in  which  requirements  may  be  formalized  (e.g..  reasonable  performance 
characteristics).  It.  plays  a  role  in  critiquing  because  the  system  can  acknow  ledge  magnitude 
errors  (e.g.,  a  screen  line  width  of  3  inches  instead  of  0.03  inches)  as  well  rts  technologra1 
limits  (e.g.,  15  MIPS  for  a  certain  machine  by  the  year  1088). 

Reasonable  values  also  pla>  a  role  in  analysis  and  validation  for  catching  errors  implied 
by  computed  values  or  by  verifying  that  values  fall  within  acceptable  limits  For  exam¬ 
ple,  while  analyzing  the  response  time,  processing  time  per  unit,  and  throughput  mr  a 
tracker,  a  value  of  10  pico  seconds  is  calculated  for  the  unit  processing  time  (figure  9', 
This  could  have  been  calculated  from  'he  response  time  (10  nano  seconds)  divided  by  the 


throughput  (1.000).  The  value  of  10  pico  seconds  for  the  unit  processing  time  is  clearly 
not  within  the  current  technology  (nano  seconds  are  about  the  current  minimum)  so  this 
‘’unreasonableness’’  will  be  critiqued  by  KBRA  (see  critiquing,  section  2  ~). 


Figure  9:  Reasonable  Value  Checks  on  Calculated  Values 
3.9.  Associative  Retrieval 

The  main  importance  of  associative  retrieval  is  the  provision  of  indexing  so  that  information 
is  retrieved  by  relations  rather  than  by  searching  the  entire  space  of  requirements  entities. 
Managing  the  “search  space”  is  a  problem  for  both  expert  systems  and  intelligent  assistants. 
Associative  retrieval  helps  manage  the  “search  problem”  by  searching  only  through  related 
requirements  entities  (KBRA’s  search  space),  rather  than  all  the  requirements  entities  that 
may  exist  in  the  entire  system.  Requirements  may  be  “related”  in  a  variety  of  ways  (e.g.. 
subfunction,  superfunction;  data  and  its  accessors;  a  name  and  things  with  that  name). 
Further  search  control  is  provided  by  limiting  the  search  to  only  one  specific  “relation" 
(e.g  ,  callers  of  a  function;  consumers  of  a  datum). 

Associative  Retrieval  provides  indexing  throughout  KBRA.  It  aids  reusability  by  providing 
controlled  access  into  a  library  of  system  compcments.  This  helps  overcome  one  problem 
with  reusable  components:  knowing  the  components  which  are  available.  Associative 
retrieval  supports  the  engineer  in  incremental  formalization  when  s  'he  is  “getting  a  handle" 
on  the  formalization  process.  KBRA  determines  the  answer  and  responds  to  inquiries 
into  where  a  certain  datum  is  used,  who  is  its  producer,  who  consumes  it,  what  text 
strings  mention  the  datum’s  name,  what  other  things  have  the  same  name,  what  names 


are  synonyms,  etc  Critiquing,  can  exploit  associative  re'.r.eva!  to  ascertain  the  respective 
roles  of  requirement  entities  Associative  retrieval  is  used  in  Explanation  by  ascertaining 
the  role  something  is  playing  in  the  system  ami  its  relat ionships  to  other  requirements 

Associative  retrieval  is  a  means  lor  determining  not  oniv  that  things  are  related  but 
also  how  they  are  related.  This  is  because  the  indices  provide  a  path  of  concept-role 
(frame-slot)  relationships  In  fact,  associative  re>rieval  is  iundamenta!  to  all  the  inference 
processes  in  KBRA  It  is  impossible  to  infer  something  if  there  is  no  relation  established 
The  other  KBRA  inference  processes  (figure  i  a )  take  advantage  of  the  associations  provided 
by  general  indexing  and  associa* ive  retrieval 

4.  Limitations  and  Possible  Extensions  to  Cui rent  Capabilities 

This  section  to  elucid  .'e  four  possible  extensions  to  the  limitations  in  the  current  KBRA 
inference  processes.  They  have  been  chosen  because  I  have  some  particularly  interesting 
ideas  on  these  extensions.  Thev  have  been  motivated  by  our  observations  of  requirements- 
level  work. 

Our  current  work  on  KBRA  in  support  has  focussed  or.  two  extremes  of  the  initiation 
of  requirements  characterization:  1.  specifying  a  complete!}  new  system  which  has  never 
been  done  before  (e  g..  SDH  or  IV  specifying  the  “next  generation”  of  a  system  (e.g  .  the 
“next  generation"  ATC  s\ stems).  We  have  not  focussed  on  incorporating  an  old  system 
of  one  type  (e.g..  patient  monitoring)  as  an  example  of  the  characteristics  for  a  different 
type  of  system  (e  g..  aircraft  monitoring,  ATC)  Johnson  .  The  possible  KBRA  extensions 
in  sections  4.1  and  4.2  address  this  issue.  These  extensions  are  admittedly  hard  problems, 
but  their  investigation  mat  yield  fruitful  results. 

4.1  Automatic  Generalization 

Currently,  all  generalization  frames  must  be  explicit!}  created.  In  the  future,  generalization 
frames  could  be  created  by  the  system  itself  in  the  form  of  abstraction  transformations 
(extracting  common  features  between  various  frames  throughout  the  system  to  make  a  new 
superclass).  This  would  particularly  aid  reusability  as  new  reusable  components  could  be 
inferred  and  then  instantiated. 

4.2.  Reasoning  by  Analogy 

There  is  currently  no  reasoning  by  analogy  in  KBRA.  It  would,  how*-. er.  provide  a  useful 
extension.  Associative  retrieval  could  be  pushed  to  reasoning  by  analog}.  assnciaMom 
could  be  inferred  b\  abstraction  transformations.  Abstraction  transformations  rouid  de¬ 
duce  commonalities  be'ween  entities  and  thus,  create  a  description  <•,:  a  higher- b"  ei  o' 
abstraction.  This  new  description  would  connect  multiple  entities  which  would  pnviousb 
have  been  unlinked.  The  new  descriptions  could  be  incorporated  into  the  *ommumt\ 
knowledge  and  could  p'av  a  role  in  reusability. 


I 


4.3.  Judgments 

There  is  currently  no  provision  for  making  judgments  based  on  the  roles  reh'ed  objects 
play  on  their  respective  entities.  Associative  retrieval  could  be  used  as  the  foandat'on  for 
such  judgments.  In  Critiquing,  the  following  may  occur:  an  t-.ititv  play-  a  certain  role 
and  is  associated  to  other  entities  which  play  various  respective  roies  in  the  system.  A 
“judgment"  could  then  be  made  on  these  relationships.  An  example  h  .hat  a  Kalman 
Filter  should  not  be  used  as  the  tracker  filter  when  military  aircraft  are  used  as  objects  to 
be  tracked.  This  is  because  the  use  of  military  aircraft  as  the  objects  tracked  precludes  the 
use  of  a  Kalman  Filter  as  the  track  filter  since  a  Kalman  Filter  is  based  on  the  assumption 
that  the  objects  being  tracked  are  not  maneuvering. 

4.4.  General  Purpose  Automatic  Classification 

Since  there  currently  is  not  a  general  purpose  classifier  as  in  N1KL  Kaczmarek.  Bates. 
Robins  or  KL-ONE  ‘Schmulze  &t  Lipkisl,  the  addition  of  such  a  classifier  would  extend 
the  current  classification  processes. 


5.  Conclusion 

There  are  many  inference  processes  within  KBRA:  inheritance,  automatic  classification, 
dependency  tracing,  local  propagation,  truth  maintenance,  contradiction  detection,  default 
reasoning,  reasonable  value  checks,  and  associative  retrieval.  These  inference  processes  are 
combined  to  actively  support  the  acquisition  and  analysis  of  requirements;  they  support 
the  incremental  formalization  of  requirements  by  providing  desirable  “intelligent  behavior" 
within  the  KBRA  system.  Thus,  the  inference  processes,  ;r.  conjunction  with  application 
knowledge,  are  where  the  intelligence  of  the  intelligent  assistant,  tor  requirements  is  found 
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Turning  Ideas  into  Specifications 


W.  Lewis  Johnson 
USC/Information  Sciences  Institute 
4676  Admiralty  Way,  Marina  del  Rey,  CA  OOitTJ 

Abstract 

Specification-based  software  development  makes  software  easiei  to  validate  ami 
maintain.  Yet  specifications  of  large  systems  are  themselves  large,  making 
understanding  and  validation  difficult.  The  specifier  usually  must  meet  a  number  of 
goals  and  requirements  at  once  in  a  specification.  Each  goal  or  requirement  m.iv  be 
straightforward  in  isolation,  but  the  underlying  simplicity  gets  lost  as  interactions 
between  requirements  are  discovered  and  tradeoffs  are  made,  in  the  Knowledge-Rased 
Specification  Assistant  project,  we  focus  on  the  steps  that  specifiers  go  thougn  in 
developing  detailed  specifications  from  initial  ideas  of  what  the  specif  cation  is  supposed 
to  do.  The  Specification  Assistant  aids  in  developing,  evaluating,  and  explaining 
specifications.  This  paper  will  discuss  the  development  aids  m  the  Specification 
.Assistant,  and  show-  how  they  help  in  the  transformation  of  requirements  into 
specifications. 
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1.  Introduction 

The  goal  of  ante  mafic  progranimii. ..  is  to  allow  pec  p!e  t  ■  describe  w  hat  t  he\  w  :t:;t  a 
computer  program  to  « i •  • ,  ;i:i  i  have  '  h<-  program  i»-  autom.o . .'nI ! y  generate  !  ,.n  t  1  w- 
of  this  description.  it  ha.-  beer,  geur:  a..;.  illumed  that  tie  program  desc-ipti.  a  w.  -uld 
take  tiie  form  of  a  formal  specification  lb  .  15 at  this  raises  a  1  undumc-nta!  quo^t ioii : 
how  do  you  know  that  the  forma:  s-  d  ion  realty  d  scribes  the  compiler  system 
that  you  have  it;  mind?  V  .Tina;  s*  eci:"',aT;...>us  are  hard  to  read,  and  their  semantics  do 
not  always  agree  with  one's  intuition.-.  ;•  is  necessary  to  ensure  that  the  specification  is 
validated  before  it  is  used  as  the  imsi-  for  implementation. 

One  way  of  mak'r.c  -.'ifK's'  ion  validation  easier  is  to  make  the  spe, 'fix  ation  fit 
way  peor>ie  thins  a.-  u:  systems  as  closely  as  possible  *2].  In  othe-  words,  the  sp-  oiler 
should  r.  i - . -  sure  that  the  terms  us.  d  in  the  specification  correspond  well  to  the  terms 
that  people  typical!  v  us-  in  t  hit./’ act  an  -  it  'lie  d<un  -tin.  Ar.ot  .*«  r  ai.sw.,  -  o  provide 

tools  wtiich  assist  people  in  interpreting  a  specification.  For  exan.j  b  .  symbolic 
evaluators  can  be  used  to  execute  the  s:.  .'cTieution  and  look  for  unintended  behavior 

[5.  O’,.  Other  analysis  bools  can  examiue  tlm  output  t ra-. cs  of  the  syn:b< die  e\  aluator. 

ami  point  out  potent: a-  probi.  m-  specifier  '191.  If  the  s; . il'irat ion  is 

paraphrased  into  some  other  medium,  such  as  ITiglish,  then  the  new  perspective  on  the 
specification  cat:  lead  to  the  discover;,  of  sp< clfication  hugs.  :18j. 


Such  t-.'htiinues  are  all  useful,  end  we  continue  to  make  use  of  them  in  our  work  with 
speed",  mi’  ns  at  1ST  However,  tt.-y  are  not  sufficient  when  mm  is  developing  a 
spe  ;i  !\t  a  large,  o-mpl'x  system.  The  pioilern  is  that  a  noR-trivh.i  com  put  c: 

system  mm-'  •ujaiiy  ne-et  a  number  f  requirements.  Some  of  these  describe  noriual- 
( as.  et  nvior-  -rs  lea!  wi’h  exceptional  muses.  One  can  easily  get  lost  in  all  the 
detail  .  Furthermore.  th>  tvais  that  a  sys'em  must  meet  may  conflict.  The  specifier 
must  m'll  ■  ’ :  a -Toffs  among  the  goal*  .  or  reformulate  the  goals  into  goals  which  do  not 
cmifi;  ■'  b  e'  various  system  components  may  be  designed  to  accomplish  some  owrai; 
system  ■  v.'h'-ch  is  rmver  explicitly  staled,  li.  general,  specifiers  make  numerous 
, lesig b.-fore  they  start  writing  t he  specifications.  As  •>  result  -  hard  to  tell 
how  ;;  ;  .  -t  it.  d  in  a  typical  specification  relate  to  the  rmi  requirements 


that  a  system  must  meet.  If  the  requirements  of  the  sy.'U  m  <  Li  .g"  o wring  the 
maintenance  phase,  it  becomes  to  difficult  to  decide  how  .  c  rec.-'.-’il-  ne  icw 
requirements  into  the  the  existing  specification. 

In  order  to  make  specifications  really  useful  and  easy  to  under/. and  and  validate,  we 
must  recognize  that  specification  development  is  a  problem-solving  process.  We  can 
the;,  try  to  build  automated  tools  that  assist  in  that  process.  F\  example,  we  can 
encourage  specifiers  to  enter  into  the  system  their  initial  ideas  about  what  a  system 
should  do.  The  system  can  then  help  the  specifiers  to  refine  and  integrate  those 
requirements,  and  compromise  them  where  necessary.  It  can  keep  a  record  of  the 
refinement  steps,  so  that  they  resulting  specification  can  be  unde 'stood  in  terms  of  high- 
level  requirements.  The  result  will  be  a  specification  that  is  more  easily  validated,  more 
easily  understandable  and  explainable,  and  henc*>  more  maintainable.  That  is  what  we 
•  Kveloping  in  the  Knowledge-Based  Specification  Assistant  rt. 

2.  Development  Assistance  in  KBSA 

Tic  Knowledge-Based  Specification  Assistant  project  is  part  of  a  larger  effort,  the 
Kn  v. judge- Based  Software  .Assistant  Project  [3l.  An  overview  of  the  Knowledge-Based 
Spe  Ifieaiion  .Assistant  Project  can  he  found  in  two  other  documents,  both  published  in 
this  volume;  "Overview  of  the  Know iedge-Based  Specification  Assistant",  and 
"Demonstration  of  the  Knowledge-Based  Specification  Assistant".  We  will  focus  here 
:  p  :i;r-  methodology  of  specification  development  that  KBS  A  supports,  and  some  of  the 
r  -  ivanced  techniques  that  KBSA  will  use  to  support  tills  methodology. 

In  tiu-  initial  stages,  the  specifier  enters  a  set  of  requirements,  using  the  Knowledge- 
Base  i  Requirements  .Assistant  [17].  The  Knowledge-Based  Requirements  Assistant,  or 
KBRA,  is  a  system  being  developed  by  Sanders  Associates.  These  requirements  can 
takf-  a  vari'-ty  of  forms,  some  formal,  and  some  in  natural  language.  It  then  passes  a 
germra!  model  of  the  domain,  together  with  the  system  requirements,  to  KBSA.  The 
Specification  .Assistant  translates  the  Requirements  .Assistant's  domain  model  into  ISfs 
specification  language,  Gist  [13,  14).  The  system  requirements  are  not  automatically 
translated  into  Gist,  because  such  a  translation  is  likely  to  reveal  ambiguities  in  the 


requirements  tm-t  won  *  uave  ;  i  "  >  .\  .  ny  n-  uner  fis.  ut-  s;  ie-r 

must  browse  throu  1;  tue  r-quiremer. •. ,  ami  mnnut.lA  r<  ii'-i**"  e.i.m  >ne  into  Gist. 

Once  the  requirements  <  at  m  ••.!  m  tin  Gx-cifica:  :>  m  'ssi®: .  the  r  ;•  aft  a 

specifi-ation  meet  i  ng,  tin*  requiren.eii'm  v.  1th  k.-'p  !’;•  n.  tin-  .Vd'.am.  During  tins 
process,  two  activi'i-s  ito.e  j  uice, 

•  1  he  specifier  identifies  trie  ..not  i.'gn-leve;  st;.'  i-.nent.-  from  among 

the  stated  requirements,  arc  htd.gs  a  *  -leve.i  sjitri n  of  the  system. 

The  high-leve:  speclfch'd  ,.u  out'i-  >  t  he  principal  goad  am:  requirements 
that  the  system  ought  t.  a  i.  ve.  it  may  not  be  :>.>.--sjp;,.  for  the 
implemented  system  to  t.cliieve  these  coats  exactly,  or  in  aii  cases.  Sue!: 
pragmatic  c  •nsiderr.'' ons  are  not  important  at  th-  high  level,  however.  The 
V  nr  pose  of  *i  •  ••'.gh-levei  specifi  •alio::  is  to  f.  >rmuiize  the  requirements  as 
straightforvur  by  ...  possible,  so  that  they  can  serve  as  the  basis  for  further 

>.Cv  •;  j  . 

•  The  sp-u  tficaiioa  is  r r:\dua' ly  e lain. rated  and  a>  take  int .  account 

the  pee  ling  spwifi.'  r  iot.  tmks.  bimphf;- ing  assumptions  e  -.riy  versions  of 
t he  specification  no:  gradtitipy  weakened.  Lx.-eptioj-.a!  •  •».-  .-  are  described. 
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high-ieve!  editing  command  to  apply  at  each  stage,  vve  ar?  currently  addressing  the 
question  of  how  to  automatically  provide  assistance  to  the  user  \r  -. Meeting  which 
■:  -mm and  to  apply. 

3.  An  Example 

Our  discussion  of  KBSA’s  development  assistance  will  focus  on  a  particular 
specification  problem,  an  air-traffic  control  system.1  The  air-traffic  control  system  is 
supposed  to  assist  controllers  in  tracking  and  controlling  aircraft  throughout  an  air 
space.  Each  aircraft  is  presumed  to  have  filed  a  flight  plan.  The  job  of  the  controllers 
is  to  ensure  that  the  aircraft  adhere  to  the  (Tight  plans.  During  an  aircraft's  flight  it 
may  travel  through  multiple  air  spaces,  each  controlled  by  a  different  air  traffic  control 
facility.  As  the  aircraft  move  from  air  space  to  air  space,  control  cf  the  aircraft  must 
be  handed  off  from  one  facility  to  the  next.  Within  a  given  facility  individual 
m  i;!  -  T-ts  may  also  hand  control  off  to  each  other. 

A  iiigi. -level  description  of  a  problem,  such  as  the  one  in  the  previous  paragraph,  can 
easily  get  buried  in  a  detailed  specification  of  a  system.  This  is  true  for  a  number  of 

masons. 

•  High-level  goals  of  the  system  are  achieved  indirect :y  bv  multiple  low-level 
system  functions.  For  example,  in  the  air-traffic  control  system 
requirements  document  that  we  studied,  the  system  was  required  to  blink 
tiie  display  of  flight  plans  that  have  not  been  explicitly  controlled  by  a 
controller.  This  indirectly  ensures  that  aircraft  stay  on  their  flight  path, 
since  assigning  a  controller  to  the  flight  is  a  prerequisite  for  ensuring  that  it 
stays  on  course. 

•  High-level  goals  may  need  to  be  compromised  in  order  to  comply  with 
properties  of  the  environment.  For  example,  aircraft  positions  are  monitored 
by  radar.  There  is  a  margin  or  error  inherent  in  these  position 
measurements.  As  a  result,  radar  tracks  can  get  lost,  and  mismatches 
between  aircraft  and  radar  tracks  can  occur. 

•  Different  system  requirements  can  interact  with  each  other.  For  instance,  a 


T1,:^  i  r  >Mcm  is  one  of  several  that  we  have  studied  in  the  context  of  the  project  Our  principal  focus 
l-  i'l-en  on  two  pro l  If-  ns  however  the  air-traffic  control  problem  and  a  hospital  information  systems 
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function  for  changing  flight  plans  must  be  included  in  tin  air  traffic  control 
system.  Su*h  a  facility  can  imoru'H  with  facilities  for  handing  off  aircraft:  if 
a  flight  plan  changes,  it  may  have  to  be  hand  d  off  to  a  iif'ferer.t  controller. 

4.  Going  from  High-Level  to  Low-Level  Specifications 

in  what  follows,  we  will  look  in  d- 1 aii  some  of  the  properties  of  high-level 
specifications,  ami  discuss  how  as  they  are  transformed  into  low-level  specifications. 
This  will  illustrate  how  the  compi-xhy  problems  are  avoided  in  IvBSA. 

4.1.  Requirements  vs.  Application  Goals 

Seine  high-level  statements  should  he  satisfied  to  the  letter  in  the  implemented 
system.  For  exar.o .  no  air. 'raft  should  be  controlled  by  more  than  one  controller  at 
once.  V>'».  rh*  requirement  to  refer  specifically  to  these  inviolable  constraints 

on  the  ?;  cm...  Ot tier  court  rain's  may  not  be  satisfied  exactly,  or  exceptional  cases  nicy 
arise  where  ’hey  are  not  satisfied  at  all;  we  call  these  application  goals.  One  such 
application  goal  is  to  cnsin  that  aircraft  foilow  their  flight  plans.  It  may  not  always  be 
possible  for  the  ATC  facility  t* .  r:u:s  aircraft  to  fcll-.m  their  flight  piano.  Nevertheless, 
stating  the  goal  rxpiii  it  !y  I.  Ips  to  <d:irifv  tiie  purpose  of  the  actions  that  the  ATC’ 
system  actually  performs. 

We  make  a  tils'  motion  here  between  application  goals,  which  are  goals  which  the 
application  must  nm-t,  an.  .lei  c'.oiunent  gt>ais.  which  describe  actions  that  the  specifier 
v  i-iies  to  5  viform  1:  miming  :  m  specification.  Application  goals  describe  desired 
behavior  ■  i  the  a;  piicati  n;  devoir-;  imm:  g.,als  describe  individual  tasks  that  the 
spe  n‘T  r  uiust  per1'  .  m  on  t  m  r.'ai  to  proinelng  a  low-level  specification  of  the  desired 
behavior.  For  ■  ii -i i  :<• .  the  sp>  ‘ifmr  may  identify  an  application  goal  that  the  airc'-af’ 
must  in  \ »  •  '•  -.Hide.  Then  barmy  th-  spe  •if-mlton  development  the  specifier  may  have  a 
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aircraf  t-pcsltlon  Cac ,  exp  ected-posi  tier.  (ac , ”) ) 

This  says  that  every  aircraft's  expected  position  is  the  same  as  V.  actual  position, 
expecteh-oosltion  would  in  turn  be  derived  from  fh-  j  ’an.* 

High-level  editing  commands  can  be  employed  to  transform  tin-  invariant  into  an 
executable  form.  One  editing  command  along  this  ro3u  is  the  command  Maintain- 
Invariant-Reactively,  which  constructs  a  demon  to  reassert  the  invariant  should  if  ever 
fail  to  hold.  It  generates  the  following: 

deir.cn  correct-position  [ac  I  aircraft] 

when  --aircraf t-position (ac ,  expected-position (ac  ?)) 
do  update?  aircraf t-position (ac,  ?)  to  expected-position (ac .  ?) 

This  demon  states  that  whenever  the  aircraft's  position  is  not  tin-  same  as  the  expected 

position,  update  it  to  be  the  same  as  the  expected  position.  Performing  such  a 

transformation  on  an  application  goal  is  called  comproviisir,.j  the  goal,  because  it  moves 

away  from  complete  satisfaction  of  the  goal  Substituting  this  demon  for  the  invariant 

is  a  goal  compromise  because  now  the  aircraft  can  go  off  course;  there  may  be  a  time 

i  •'  ay  bet  wren  when  the  aircraft  goes  off  course  and  when  the  demon  corrects  it. 

Not  only  does  IvBSA  provide  the  necessary  editing  commands,  it-  also  provides  a  check 
"!  ensure  that  application  goals  are  kept  distinct  from  requirements.  By  default,  any 
invariant  is  considered  a  goal,  and  can  be  compromised.  However,  the  user  may  mark 
an  expression  as  a  requirement,  in  which  rase  meaning-changing  high-level  editing 
mm::. amis  cannot  fie  applied  to  the  expression. 

1.2.  Perfect  Knowledge 

In  high-level  specifications,  we  specify  systems  without  regard  for  what  data  is 
accessible  to  which  agents  in  the  system.  All  agents  are  presumed  to  have  perfect 
km-wh-dc"  about  the  actions  and  properties  of  all  other  agents.  Goals  and  requirements 
•a:.  he  defined  in  the  most  concise  manner  possible.  As  high-level  specifications 

‘la  ^<o-  syntax  tie-  symbol  I  means  “is  of  type",  II  means  “such  that"  The  symbol  ?  always 
•i;  '"*r  mo  b-  some  relational  expression;  it  refers  to  some  object  for  which  the  relation  holds  Thus 
exp  ‘  'ted  ■ position (ac . ,)  is  equivalent  to  the  position  II  expected-position  (ac , 
r  sitiord,  14  !<■>:  a  description  of  Gist  syntax. 


are  refined  into  !ov,  h-v-'  specifications,  datn-aecess  consicseration?  are  introouced:  the 
specification  of  each  aceiit  is  refonnu.ated  so  that  its  behavi  >r  if  described  only  in  terms 
of  the  information  available  to  it. 

For  example,  when  a  plane  arrives  m  ; he  airspace  >..{  an  air-lraflic  control  facility,  the 
controller  who  is  supposed  to  assume  control  of  the  aircraft  should  be  notified. 
However,  the  air-traffic  control  system  'a:;.,  :  directly  observe  aircraft  posit’:  »ns:  it  can 
only  observe  radar  data.  These  data  may  have  errors,  and  furthermore  it  is  impossible 
determine  directly  wl  icn  aircraft  corresponds  to  which  radar  track.  The  correspondence 
can  only  be  inferred  by  examining  the  flight  plans  for  aircraft  that  are  expected  to 
arrive. 

An  exam;  V  of  a  high-level  editing  command  which  assists  in  the  transformation  of 
this  goal  is  the  command  Splice,  which  is  described  in  some  detail  elsewhere  14,  lib 
This  command  replaces  references  to  a  relations  that  should  not  be  observable,  e.g., 
aircraft-position,  with  a  new  relation  track-posltl on,  which  is  computed  by 
the  radar.  Splice  also  add.--  an  Invariant  constraining  the  track's  position  and  the 
aircraft'-  position  be  the  sain-.  As  Mbs  invariant  is  weakened,  the  specification 
becomes  more  realistic  (and  more  complex). 

In  order  to  motivate  me  use  of  Splice,  one  must  make  clear  what  data  is  accessible  to 
which  agents.  We  provide  the  specifier  with  an  annotation  language  for  describing 

hich  agents  -an  ac-css  which  data,  e.g., 

relation  aircraft-position  inaccesslble-by  ate- system 

'I’li-  specifier  firs:  write  specifications  assuming  perfect  knowledge,  and  then  add 
annotations  describing  data  accessibility.  Analysis  of  how  data  is  used  in  a  specification 
can  then  identify  agents  a  hi  eh  access  data  which  should  be  inac-essible  to  them;  the 
-pecifi-r  may  Mm:  ei;  pim  common  -m  b  as  Splice  i*  •  correct  Mk  information  flow. 
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4.3.  Unlimited  Capabilities 

Just  as  it  is  convenient  to  describe  agents  ns  if  they  had  ;  meet  i  novVdge,  it  is 
convenient  to  describe  describe  them  as  if  they  had  unlimited.  on;vib  ihi  .  That  is. 
agents  can.  affect  the  environment  directly,  without  gob.;;  th  round  some  intermediate 
agent.  A  good  example  here  is  keeping  the  aircraft  or  course.  In  tne  demon  shown  in 
Section  4.1,  the  aircraft's  position  is  being  direct i\  updated.  in  the  low-level 
specification,  some  procedure  will  have  to  be  defined  whi-Ji  will  have  the  effect  of 
causing  the  aircraft's  position  to  change  (e.g.,  send  a  coma  •  correction  request  to  the 
piiot  of  the  errant  aircraft). 

The  notion  of  the  air-traffic  control  system  "updating"  the  aircraft’s  position  may 
seem  strange.  In  order  for  it  to  make  sense,  think  of  updvhig  not  as  modifying  some 
fact  in  a  database,  but  as  causing  some  fact  to  be  true  in  the  ••••oHd.  By  ignoring  at  the 
hie!:  ’•••.  <•  ’  what  capabilities  agents  have,  one  can  describe  a  hat  events  agents  cause  to 
iiappen,  without  describing  how  they  cause  term  to  happen  This  ability  to  describe 
"v.'.'.at"  instead  of  "how"  is  what  distinguishes  specifications  from  implementations.  In 
this  way  low-level  specifications  can  be  regarded  as  implementations  of  high-level 
specifications  [9j. 

U.  order  to  distinguish  "updating"  from  "causing  to  happen ",  and  in  order  to  guide 
refinement  of  the  high-level  specification,  tin-  specifier  must  indicate  which  data  is 
moulfianie  by  which  agents.  This  is  done  using  am  Citations,  as  was  the  case  in 
:•  '  accessibility  of  information. 

T n  tl.  of  i-scribing  effects  regardless  of  whether  or  not  an  agent  is  capable  of 
■audnu  ef<>c*>  **xJ»*n  B  beyond  the  issue  of  modifiability  of  data.  It  is  sometimes 
uv-u'*  •  i'-'^rii  ■  an  effect  even  if  no  agent  in  the  system  has  a  method  for 
■  '  •  '  ‘T*  in  d.  the  specifier  may  use  the  achieve  operator,  a  high- 

a;  plie.i  to  Gist  definitions.  This  achieve  operator  is  similar 
a;-  1  eve  ■  -  n  •  f  I>ershowitz  [8],  For  example,  we  could  use  the  achieve 

.  r*  rrect -position  demon  as  follows: 

1  c ~  :  ccrrect-r.'  “ItlonCac  I  aircraft] 


when  —aircraft-position  -.ac  .  expected-position  uc .  ?)) 
do  achieve []  postcondition 

aircraft-position (ac ,  expected-pcsl tlon (a; ,  ?)) 

The  presence  of  .m  achieve  operator  indicates  that  tlu-  specification  is  operationally 
incomplete;  some  action  must  be  added  which  causes  the  stated  postcondition  to  be 
true.  Pure  Gist  is  has  fully  operational  semantics:  if  a  predicate  is  to  be  true  in  a 
behavior,  then  the  specifier  mu.-;  defim  s; •me  procedure  or  demon  which  is  capable  of 
making  the  predicate  true.  Tin  achieve  operator  violates  this  condition.  Thus  each 
achieve  operator  ultimately  leads  3  development  goal  being  posted  to  supply  an 
implementation  for  the  achieve  operator. 


achie 


art  sometim--  introduced  bv  high-level  editing  commands  tc 


indicate  wuere  details  must  be  filled  in.  The  command  Mai ntai n-Invari an ;-R eacti vely 
sometimes  does  this.  If  it  is  unable  to  determine  h<-w  to  write  a  demon  to  cause  an 
invariant  to  be  satisfied  with  'lie  permitted  capabilities,  it  will  insert  an  achieve 
operator  in  the  demon,  as  in  ti.e  above  example.  The  specifier  can  then  fill  in  the 
details  that  tic-  command  did  not  know  how  to  fill  in. 


5.  Guiding  the  Refinement  Steps 

Most  of  our  development  effort  so  far  has  been  directed  toward  construction  of  high- 
level  editing  commands  to  support  our  specification  refinement  methodology.  However, 
high-level  editing  commands  are  only  part  of  what  one  would  need  for  highly  automated 
development  assistance.  We  would  ultimately  like  KBSA  to  take  a  more  active  role  in 
the  dev t  1 .  pment  process.  We  can  see  what  role  high-level  editing  commands  play  by 
regarding  specification  dev<  lopment  as  traversing  a  problem  space.  Each  state  in  this 
space  a  partial:;.-  .mmpb-ted  specification.  The  specifier  is  attempting  to  reach  some 
goal  state,  in  which  a  specification  which  adequatelv  meets  the  specifier's  requirements 
has  been  constructed  High-level  editing  commands  are  the  operators  that  move  from 
one  state  tc;  the  next.  KBSA's  responsibility  currently  is  to  execute  the  operators  that 
move  the  sp-eirm-uion  from  problem  state  to  problem  state.  The  user  must  decide 
whether  or  not  a  :  o.f,  state  has  been  reached,  and  if  not  what  operator  to  apply. 
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w  e  see  the  process  of  deciding  what  high-level  editing  command  i'>  »p'f  ;>  as  !; Hows. 

•  The  user  starts  with  some  expectations  of  what  the  goal  state  >  sr.ou.d  io  ;k 
like.  That  is,  he  is  able  to  analyze  or  validate  a  specif. ration,  and  dm  ermine 
whether  or  not  it  is  complete.  These  expectations  ma\  h.*  gen'-mu  well- 
formedness  conditions  that  any  completed  specif  ion  of  my  problem 
should  meet.  For  example,  in  a  completed  specification  ah  ug< :..ts  should 
buna  a  well-defined  set  of  input  and  output  data  paths.  Tl’er  i  ili.e'y,  there 
may  be  problem-specific  expectations:  the  specif  *:  has  a  cm",  ain  kind  of 
system  in  mind,  and  will  be  satisfied  what  the  speff -ati- m  matches  his 
intentions. 

•  The  expectations  are  used  to  identifies  an  issue  in  the  specification  that 
need  to  be  resolved.  That  is,  the  specifier  decides  that  ‘ome  particular 
aspect  of  the  specification  needs  refinement.  For  example.  ’he  fact  that  the 
definition  of  monitor  referred  to  readings  was  an  issue  that  nc-d .d  to  be 
resolved. 

•  Selection  of  an  issue  results  in  a  development  goal  being  ported;  in  other 
Vo  -  !«.  the  specifier  has  the  goal  of  resolving  the  issue.  The  above  issue  of 

h  monitor  referring  to  readings  results  in  the  goal  of  eliminating 
references  to  readings  within  monitor. 

•  Finally,  an  editing  command  is  selected  to  achieve  the  development  goal, 
based  upon  knowledge  of  what  kinds  of  goals  each,  editing  command  is 
capable  of  achieving. 

iVe  are  currently  undergoing  efforts  to  allow  ivBSA  to  contribute  to  the  decision 
;  r  'C(;>«  at  each  stage.  First,  we  are  developing  classifications  for  the  type  of 
development  goals  that  high-level  editing  commands  achieve.  Tiiese  goals  fit  into 
genera!  classes,  such  as  "move  towards  implementation',  as  well  as  specific,  such  as 
"reroute  a  data  path".  If  the  user  states  his  or  her  goal,  the  system  can  suggest 
n;  ;  1'  -ar.’ic  editing  commands. 

[evaluating  expectations  and  identifying  issues  is  both  promising  and  problematic. 
Soi.it-  kinds  of  expectations  are  easy  to  test,  given  the  representation  of  specifications 
that  w c  anv"  beer,  developing.  For  example,  a  complete  specification  should  not  contain 
any  achieve  operators;  each  achieve  is  a  potential  issue  to  be  resolved.  We  are 
d'-vei  >pir,g  analysis  too’;.,  for  checking  other  kinds  of  expectations,  some  of  which  are 
d  in  pf.  FT'  1  I'-m-specific  expectations,  however,  require  KBSA  to  have  more 
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knowledge  about  the  specification.  This  knowledge  must  ultimately  come  lrom  the 
user.  We  therefore  are  faced  with  a  tradeoff  situation:  when  will  a  user  find  it 
advantageous  to  describe  his  expectations  to  the  system,  and  when  will  he  prefer  to  do 
the  analysis  himself0  We  art  in  the  process  of  empirically  evaluating  this  question.  In 
the  mean  time,  we  are  including  representations  in  KBS  A  for  a  wider  range  of 
specification  knowledge,  such  as  what  data  is  observable  by  whom,  and  whether  or  not 
high-level  requirements  can  in  compromised.  We  then  build  high-level  editing 
commands  that  would  be  selected  on  the  basis  of  this  knowledge,  and  determine 
empirically  which  is  the  most  satisfactory  way  of  controlling  the  specification 
development. 


6.  Relation  to  Other  Techniques 

The  method  of  constructing  high-level  specifications  and  refining  them  into  low-level 
specifications  bears  some  resemblance  to  informal  methods  of  requirements  elicitation 
(e.g..  [7,  12;).  .As  in  these  other  methods,  the  specifier  attempts  to  describe  some  aspects 
of  a  system  as  directly  as  possible,  while  ignoring  other  aspects  of  the  system.  Where 
we  differ  from  other  techniques  is  in  the  order  in  which  we  specify  things.  In  DeMarco’s 
technique,  for  example,  one  specifies  data  flow  first,  and  does  not  start  specifying  the 
functionality  of  the  system  until  after  the  data  flow  is  mapped  out.  One  never  specifies 
the  requirements  of  the  system  as  a  whole;  instead,  one  specifies  the  requirements  on 
each  node  in  the  data-flow  graph.  In  our  approach,  one  starts  by  describing  the 
requirements  and  goals  for  the  system  as  a  whole,  and  then  starts  to  define  the  data¬ 
flow  organization. 

The  advantage  that  we  see  in  the  IvBSA  approach  is  that  the  specification  is 
operational  even  at  the  high  level.  That  is,  it  is  possible  to  symbolically  execute  high- 
level  specifications.  The  name  is  not  true  for  data-flow  diagrams.  Psychological  studies 
of  software  design  [ 1 ,  15;  point  to  the  importance  of  "mental  simulation"  as  a  tool  for 
analyzing  partial  designs.  Using  KBSA.  a  specifier  does  not  have  a  simulate  a 
specification  in  his  or  her  head;  KBSA  can  do  the  simaiafon  automatical!''. 

High-l-'vel  specification:-  are  particularly  important  in  deciding  how  to  introduce 
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computing  systems  into  an  organization.  Using  DeMarcos  data-;!  e,v  appioacli.  tor 
example,  requirements  analysis  first  involves  sketching  the  data  flow  m  t'e  existing 
organization.  Then  when  the  time  comes  to  describe  how  the  new  computing  system 
will  affect  the  organization,  it  is  necessary  to  identify  .m  of  the  du  a-f.ow  nodes  that 
might  he  affected,  draw  a  circle  around  these  nodes,  erase  everything  inside  the  circle, 
and  redesign  the  contents  of  the  circle  from  scratch.  Thus  there  hs  no  assurance  that 
the  iv’w  system  organization  meets  the  same  requirements  that  tm-  old  organization 
does.  Using  our  approach,  the  high-level  requirements  and  application  goals  carry  over 
into  the  new  system  organization,  simplifying  the  redesign  task. 

At  the  same  time,  we  recognize  that  data-flow  diagrams  are  a  useful  technique  for 
doing  requirements  analysis.  The  Requirements  Assistant  provi  les  support  for  data¬ 
flow  diagrams,  and  rightly  so.  In  the  ideal  case,  presentation  techniques  such  as  data¬ 
flow  diagrams  and  goal  refinement  capabilities  would  he  integrated  into  a  single  system. 
At  that  point,  the  distinction  between  requirements  analysis  and  specification 
development  would  break  down.  Both  would  be  aspects  of  the  same  process,  one  of 
developing  formal  specifications  from  ill-defined  requirements. 


7.  Conclusions  and  Future  Research 

IvBSA's  approach  to  specification  development  shows  j. remise  as  a  way  of  allowing 
s’  ‘•rifiers  to  state  their  goals  for  a  system  as  concisely  as  possible,  and  build  them  into  a 
'•e  he  rent  specification.  Already  we  find  that  the  high-level  editing  commands  that  we 
are  developing  are  used  over  and  over  again  in  a  variety  of  contexts.  We  intend  to 
••'•tititiu"  to  develop  this  library. 


The  next  major  test  for  this  approach  is  to  use  it  as  a  basis  for  explanation.  We 
believe  that  specifications  that  have  been  developed  from  high-level  specifications  are 
'•ader  to  understand.  In  fact,  it  should  be  possible  for  KE^SA  tc  generate  explanations 
for  c  ificaticns  automatically.  The  record  of  specification  development  will  thus 
:  une  more  than  a  corporate  memory:  it  will  be  come  a  corporate  consultant,  able  to 

lain  software  systems  to  people  who  were  not  involved  in  developing  the 
a  fun:  ions.  If  we  arc  successful  in  this  regard,  then  the  refinement-based  approach 


will  shown  to  he  than  much  more  powerful. 
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Technology  Focus 

(1)  Creation  of  a  new  paradigm  for  software  systems  design 
and  life  cycle  management. 

Transition  to  a  view  of  software  design  information  (in 
the  form  of  specification  and  design  components)  as  an 
asset  that  accumulates  and  that  can  be  applied  to  many 
problems. 


(2)  Embodiment  of  research  results  in  the  form  of 

environments  for  design  and  maintenance  of  systems. 

Explicit  transition  approach  involving  the  Ada,  Lisp, 
and  scientific  communities. 
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•  DESIGN:  Retention  and  Management 

Objective :  Retain  and  apply  design  information 
gained  during  software  development. 


Rationale :  Programs  describe  machine  behaviors, 
but  do  not  contain  enough  design  information  to 
describe  the  intent  of  the  behaviors. 

Programmers,  maintainers,  and  verifiers  require 
this  design  knowledge  and  must  now  recover  it  at 
great  expense. 


Impact :  Direct  use  of  design  information  will 
enable  use  of  a  new  paradigm  based  on 
accumulation  and  application  of  design  assets. 
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•  DESIGN:  Adaptation  and  Reuse 


Objective :  Build  tools  to  support  the  creation  of 
systems  whose  design  components  are  reusable. 


Rationale:  The  abstract  nature  of  software 
creates  a  great  potential  for  adaptability. 


Current  methodologies  and  languages  nonetheless 


yield  systems  that  are  overcommitted  and  brittle. 


Impact:  Software  tools  will  enable  acquisition 
and  use  of  design  information  to  rapidly  adapt 
already  deployed  systems. 

Tools  will  assist  in  sustaining  trust. 
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•  PARALLELISM 


Objective:  Create  software  technology  to  enable 
full  exploitation  of  the  potential  power  of  the 
parallel  computing  architectures. 


Rationale:  Current  languages,  algorithms  and 
tools  are  oriented  toward  sequentiality. 

Software  technology  progress  is  required  for 
systems  scalability,  reliability,  and  full  exploitation 
of  parallel  performance  potential. 


Impact:  Languages,  algorithms,  and  tool 
support  will  provide  open  access  to  scalable 
architectures. 
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Software  Systems  Design 


Management  and  Transition  Strategy 

(1)  Quality.  Use  of  the  best  research  groups  and  best 
resources.  Creation  of  new  organizational  structure  in 
the  community  to  facilitate  creation,  sharing,  and 
transition  for  a  new  culture. 

(2)  Scarcity  of  high  quality  groups  requires  explicit 
management  and  transition  to  new  approaches. 

(3)  Explicit  attention  to  engineering  in  support  of  the 
research  activity  and  in  support  of  transfer. 

Top-dowm  vision,  bottom-up  realization. 

No  monoliths. 

(4)  Development  and  sharing  of  component  technologies, 
including  subsystems,  languages,  and  conventions  for 
abstract  interfaces. 

Transition  of  current  prototypes  into  enabling 
technologies  for  next  generation. 

Subsystems:  Mach,  X,  [Syntax],  [OOdb],  ... 

Languages:  Ada,  Lisp.  WSLs,  SpecLgs,  ScientificLgs,  ... 

Conventions:  OOdb  access,  Unix  files,  ... 

(5)  Confluence  of  three  major  participating  communities. 

(6)  Transfer  plan  with  Ada  community,  SEI,  Lisp. 

(7)  Explicit  attention  to  foundational  work  in  support  of 
programmatic  goals. 
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Abstract:  We  describe  an  architecture  for  providing  intelligent  assistance  to  the  programmer 
carrying  out  the  process  of  programming.  This  architecture,  based  on  an  AI  planning 
paradigm,  can  provide  both  passive  and  active  assistance.  Passive  assistance, 
accomplished  by  plan  recognition,  is  used  to  detect  and  avert  process  errors.  Active 
assistance,  accomplished  by  planning,  is  used  to  automate  the  programming  process.  A 
key  issue  in  achieving  appropriate  levels  of  assistance  is  the  ability  to  capture  complex 
domain  knowledge  in  a  planning  formalism.  We  illustrate  several  problems  in  traditional 
hierarchical  formalisms,  and  propose  a  solution  based  on  the  use  of  meta-plans  that 
dynamically  transform  plans. 


Development  environments  of  today  provide  little  assistance  to  me  programme!  with  the 
process  of  programming.  The  tasks  of  mapping  programming  goals  into  sequences  of  tool 
invocations,  revising  plans  when  results  are  not  as  expected,  and  performing  the  required 
—  but  mundane  —  housekeeping  chores  such  as  file  management  are  earned  out  with  only 
rudimentary  support.  As  new  techniques  are  developed  to  automate  some  part  of  the 
process,  a  new  tool  is  created  (or  an  existing  tool  expanded)  This  leads  to  a  situation 
where,  by  definition,  the  process  of  programming  comprises  all  the  activities  that  cannot  be 
fully  automated. 

This  inability  to  provide  full  automation  does  not,  however,  preclude  other  forms  of 
assistance  Two  possibilities,  based  upon  reasoning  about  the  programming  process, 
appear  promising.  In  or  case,  the  programmer  retains  the  inivu  -  e  for  performing  the 
process,  issuing  commands  exactly  as  at  present.  A  passive  intei’  .gcrt  assistant  monitors 
these  actions,  measuring  them  against  its  (extensive  but  stii!  incomplete,'  knowledge  of  the 
process.  In  this  mode,  many  types  of  process  errors  could  be  detected  and  averted.  Such 
an  assistant  would  be  an  automated  version  of  a  colleague  watching  over  the  shoulder  of  a 
programmer  at  work.  In  the  second  case,  the  programmer  relinquishes  control  to  the 
intelligent  assistant,  specifying  only  goals  to  be  achieved  rather  than  the  detailed  commands 
by  which  they  are  to  be  achieved.  Here,  an  active  intelligent  assistant  plans  a  sequence  of 
commands  using  its  knowledge  of  process  actions,  since  its  knowledge  is  incomplete,  the 
programmer  must  supply  certain  decisions  which  are  beyond  the  scope  of  the  assistant  In 
this  mode,  a  cooperative  automation  of  the  process  is  achieved 

1.1  Architecture  for  Intelligent  Assistance 

We  are  developing  an  architecture  (diagrammed  in  Figure  1)  that  provides  both  of  these 
forms  of  assistance  in  order  to  offer  the  programmer  a  very  powerful  and  flexible  support 
environment  Our  approach  is  based  on  the  use  of  AI  planning  techniques,  which  offer  a 
we II -developed  framework  for  reasoning  about  actions.  Planning  technology  represents 
one  possible  route  towards  "process  programming"  [14],  a  concept  that  is  the  subject  of 
current  debate  [10].  The  plan -based  architecture,  named  GRAPPLE  ,  that  we  are  currently 
developing  [2]  builds  upon  earlier  work  in  intelligent  assistant  architectures  [’,3,5,6] 


Under  a  planning  paradigm,  knowledge  of  the  process  is  expressed  as  operators  defining 
the  legal  actions  of  programming,  together  with  a  state  schema  defining  the  predicates  that 
describe  the  state  of  the  programming  world.  A  plan  is  a  partial  order  of  operators  (with  all 
variables  bound)  that  achieves  a  goal  given  an  initial  state  of  the  world.  The  algorithms  for 
monitoring  programmer  actions  are  the  algorithms  of  plan  recognition,  where  a  plan  to 
achieve  some  goal  is  identified  incrementally  from  sequences  of  actions  performed  by  the 
programmer.  The  algorithms  for  carrying  out  a  programmer  goal  are  the  algorithms  of 
planning,  where  a  partial  order  of  operators  is  generated  to  achieve  the  stated  goal. 

A  major  benefit  of  this  approach  is  that  the  intelligent  assistant  is  domain-independent. 
Merely  by  changing  the  library  of  operators  and  associated  state  schema,  alternative 
programming  processes  or  different  toolsets  may  be  accommodated;  tailoring  the  assistant 
to  project-specific  policies  is  similarly  accomplished.  Enlarging  the  library  of  operators 
allows  coverage  of  additional  life-cycle  phases  (and  the  all-important  feedback  loops  among 
phases).  The  intelligent  assistant  can  act  at  the  operating  system  command  level  and/or 
within  a  complex  tool  (by  considering  the  functions  provided  by  the  tool  to  be  tools 
themselves.) 
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1.2  Processes  as  Plans 

As  a  test  domain  for  this  intelligent  assistant,  we  are  exploring  the  programming  process  as 
it  is  earned  out  for  a  traditional  programming  language  such  as  C  at  the  command  level  in 
an  existing  operating  system,  UNIX™,  assuming  a  style  that  follows  accepted  engineering 
practice.  A  partial  library  of  operators  for  this  domain  is  sketched  m  Figure  2;  these 
operators  have  been  greatly  simplified  for  purposes  of  this  example,  but  should  serve  to 
indicate  the  general  nature  of  the  approach. 


The  operator  definitions  follow  standard  state-based,  hierarchical  planning  approaches 
[15,17,19].  In  a  state-based  approach,  each  operator  has  a  precondition  defining  the  state 
that  must  hold  in  order  for  the  action  to  be  legal,  and  a  set  of  effects  that  defines  the  state 
changes  that  result  from  performing  the  action.  These  core  clauses  are  augmented  by  a  goal 
clause  that  defines  the  principal  effects  of  an  action  (thus  distinguishing  them  from  "side- 
effects”  of  the  action),  and  a  constraints  clause  that  defines  restrictions  on  parameter  values. 
A  hierarchical  approach  supports  multiple  levels  of  abstraction  in  operators  by  allowing  the 
definition  of  complex  operators  having  subgoals  that  decompose  the  operator  into  simpler 

UNIX  is  a  registered  trademark  of  AT&T  Bell  Laboratories. 
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subproblerr/.  Primitive  operators,  which  do  not  have  subgoais,  correspond  to  the  atomic 
actions  in  the  domain. 


The  basis,  data  structure  of  a  planner  or  plan  recognizer  is  a  hierarchical  plan  network  as 
first  developed  in  [15’.  An  example  of  such  a  network  (using  some  of  the  operators  of 
Figure  2)  is  giver,  in  Figure  3  There,  a  vertical  slice  through  a  network  covering  three 
hierarchical  levels  is  shown,  with  the  highest  level  at  the  top  of  the  figure.  Downward 
arrows  between  levels  connect  desired  states  w>tn  operators  instantiated  to  achieve  them 
Such  instan'  ated  operators  consist  of  additional  states  describing  the  internals  of  the 
operator;  preconditions,  subgoals,  and  effects  Arrows  within  levels  snow  how  the 
achievement  of  certain  states  is  partially  ordered  with  re.pect  to  time.  Some  ordenngs  are 
dictated  by  the  operator  definitions:  precondition  states  must  always  precede  subgoais,  for 


example  Other  orderings  are  imposed  to  resolve  interactions  between  opemror,  that  could 
destroy  the  plan  Orderings  are  propagated  from  level  to  level,  t  ut  ha'-e  been  omitted  *o 
simplify  the  figure. 

Both  planning  and  plan  recognition  involve  building  a  complete  plan  ne(  •  a- it  This  is  done 
by  actions  such  as  choosing  operators  to  achieve  states,  instantiating  tiicse  operators,  and 
resolving  conflicts  between  newly  revealed  states  and  existing  states.  Tin  strength  of  a 
planning  approach  lies  is  this  ability  to  handle  conflicts  that  would  otherwise  destroy  a 
plan  For  example,  consider  a  situation  where  an  operator  has  a  two  part  precondition, 
requiring  that  both  A  and  B  be  true,  and  the  only  operator  available  fc  .’.chieving  B  also 
achieves  NOT  A.  Any  plan  that  allowed  the  operator  for  achieving  B  to  follow  the  operator 
for  achieving  A  would  fail,  due  to  this  interaction  of  the  operators  A  viable  plan  must 
require  that  the  operator  to  achieve  B  precede  the  operai-y  to  achieve  a.  Wr  ile  re-ordering 
operators  solves  a  common  type  of  interaction,  other  meat.:-  f  com  i  ?t  rcyv'.i  tier.  have  also 
been  developed  [15.17,19], 

Planning  techniques  are  needed  when  the  chosen  problem  representation  t.us  rules  that  are 
not  decomposable  [13],  i.e..  when  solutions  to  parallel  subproblems  cannot  be  tackled 
independently  and  trivially  recombined  Certain  types  of  production  rules  (and  expert 
systems  based  on  them)  assume  decomposabilhy.  While  such  rule  systems  have  been  used 
to  handle  some  types  of  process  automation  for  p'ogr  lm.ners  ]9j  the  approach  is  not 
readily  extensible,  for  example,  the  precondition  in  ert  '  on  dm-cNbcd  above  cannot  be 
handled.  Additional  interactions  are  certain  to  am  r  a  hen  mr.lb-'ic  plans  are  simultaneously 
in  progress,  as  is  often  the  case  with  program— ir  :  w  u  k  For  example,  when  a 
programmer  is  both  fixing  a  hug  in  an  old  version  of  a  •  ystrm  a. id  audmg  new  functionality 
in  the  ia’est  version,  different  directories  must  bo  lo-d  to  separate  the  two  sets  of  source 
and  object  modules. 

1 J  Assistance  from  a  Planning  Perspective 

Together,  planning  and  plan  recognition  make  it  possible  to  deliver  a  broad  range  of 
services  to  the  programmer  The  planning  perspective  suggests  ways  that  the  specific 

serv  ices  can  r>e  accomplished: 


Agendas  and  Summaries: 

An  agenda  is  the  set  of  goals  yet  to  be  satisf’ed  in  a  plan,  and  a  summary  is 
the  set  of  goals  that  have  been  satisfied.  Etther  can  be  described  at  various 
levels  of  abstraction,  given  the  hierarchical  nature  of  the  plans.  Both  are 
"intelligent"  in  that  the  system  has  the  knowledge  to  interpret  what  they 
mean:  for  example,  a  plan  for  carrying  out  an  agenda  item  can  be 
constructed. 

Error  Detection: 

Three  different  classes  of  errors  can  be  handled  Logistical  errors  represent 
faulty  planning  by  the  programmer.  Examples  are  executing  an  action 
before  its  precondition  is  met,  or  undoing  a  previously  satisfied 
precondition  before  the  relevant  action  has  started.  Housekeeping  errors 
represent  errors  of  omission.  Examples  are  keeping  files  in  the  "right" 
directories,  checking  sources  back  into  a  source  code  control  system, 
deleting  extraneous  file;.,  and  perhaps  adhering  to  certain  project-specific 
policies  The  final  class  of  errors  are  substantive  software  process  errors: 
for  cxarr.pl*',  violating  constraints  in  operators  such  as  making  the  wrong 
choice  of  a  baseline  from  which  to  develop  a  new  system. 

Error  Correction: 

The  error  correction  facilities  amount  to  an  "intelligent"  do-what-I-mean. 
Types  of  corrections  (related  to  the  types  of  errors  described  above)  include 
re-ordenng  actions,  identifying  missing  activities,  supplying  a  plan  to 
satisfy  a  required  state  and  substituting  bindings  that  satisfy  required 
constraints. 

Query  Support: 

Queries  us  to  either  the  state  of  the  world  or  the  state  of  the  actions  can  be 
handled,  since  both  states  are  maintained  to  support  planning  functions. 
Each  state  represents  a  "database”  of  information  about  current  status  and 
past  history 

Cooperative  Automation: 

The  automation  itself  is  achieved  by  planning.  Cooperation  is  accomplished 
by  requesting  programmer  decisions  on  such  issues  as  what  parameter 
bindmcs  to  use  in  operators,  when  io  terminate  iterated  activities,  or  how  to 
select  among  alternative  operators. 


1.4  Achieving  Intelligent  Assistance 


The  architecture  we  have  described  is  an  ambitious  one,  Whi.i,-  niunre.ng  ;-.p  z:z:  to  be  the 
right  framework  for  reasoning  about  a  process,  the  ley  :r.  be  r .  abb:  careur  all  the 
relevant  process  knowledge  in  the  operator  definitions,  if  too  iir.’>  k:.  'edge  is  captured, 
the  intelligent  assistant  will  be  rigid,  and  ultimate!;,  more  constrictive  than  supportive.  The 
challenge  anses  because  the  programming  process  is  ai  lc.  st  a  ccmp'-ex  as  any  domain 
previoulsy  tackled  for  a  planning  application.  Ar.u  certain  aspects,  such  as  the  inherent 
"trial  and  error"  nature  of  programming  and  the  fact  thaf  ’he  lrtcil.gen.  assistant  is  not 
intended  to  be  fully  autonomous,  are  novel. 

As  a  result  of  designing  an  operator  definition  language  engineered  u.  handle  real-world 
domains  [7]  and  writing  software  process  operators  re  tins  dreg'  ..gu  1  rfj,  we  have 
encountered  limits  to  the  representational  adequacy  c."  exivjng  luerareh  plan  formalisms. 
There  are  problems  in  capturing  such  relevant  domain  knowledge  ..  -rev.  to  recover  when 
an  operator  fails  or  when  to  us;  special  case  remuors  Thv  ingC'  ...  to  provide  this 
knowledge  in  a  way  that  is  tractable  both  to  the  plan;.;;  c  algorithms  and  to  ’re  writer  of  the 
domain  operators. 

In  the  remamder  of  this  paper,  we  illustrate  the  problem  of  representational  adequacy  with 
examples  of  software  processes  We  introduce  a  solution  u  J  upon  dynamically 
transforming  plans,  as  opposed  to  defining  ;*  f  tin- a]  (surer ,  ope  rotor  definitions.  We 
discuss  how  the  transformations  are  formalize."  .  c  -  ore  sod  as  r  ut?  revel  operators;  both 
the  state  description  and  required  operator  c  istru.  ’s  are  rev  cre.i  finally,  we  present 
status  and  conclusions. 


Hierarchical  plan  systems,  based  on  NOAH  |!5,  and  NONLDM  [17],  have  strengths  both 
in  their  planning  algorithms  and  in  the  nature  of  their  operator  definitions.  When 
desenbing  a  complex  domain,  the  hierarchical  approach  is  appealing  because  activities  can 
be  defined  at  different  levels  of  abstraction,  with  more  or  less  detail  as  appropriate. 
Another  strength  lies  in  the  modularity  of  operator  libraries:  operators  can  be  written 
without  knowledge  of  the  other  operators  in  the  library,  and  operators  are  potentially 
applicable  in  any  context  where  their  goals  match  the  preconditions  or  subgoals  of  other 
operators  in  complex  domains,  cases  arise  where  appropriate  expressive  power  is  lacking 


in  the  operator  formal  ism.  utten-pts  te  describe  cervir.  operate  accurately  car.  jeopardize 
the  library  modularity  .  or  .  -'nrigr:  Consider  me  following  problems. 

2.1  Limits  or.  Kcpresen'aviouJ  Power 

Adding  special  ca»e  operators  tc  ;•  library  may  -.^ire  that  preconditions  or  subgoals  of 
existing  operators  be  rewritten.  tv-  m  ampk .  ••  .cn  testing  a  system  that  is  intended  to  fix 
certain  bugs,  the  programmer  she  uld  a- a  th.t  c-ffic  u'  testcases  associated  with  those  bugs, 
in  addition  to  those  tes  tease ,  ir.ai  wouid  oil  .cruise  be  ,eiected.  One  solution  is  to  write  a 
separate  operator  coveru.g  a.:  tcsumig  .leetiud  *l::r.  bugs  are  being  fixed,  its  precondition 
restricts  its  applicability  to  systems  interned  to  fix  t-gs  Now  there  are  two  operators  for 
testing  that  are  intended  u-  nr..ua!i\  exciusis e  Therefore.  the  normal  operator  for 
testing  must  specif'  ns  nr— .md'Uon  that  it  is  not  applicable  to  cases  where  bugs  are 
being  fixed' 

In  other  situations,  exi ig  operators  must  be  rewritten  in  artificial  wavs  Consider  testing 
a  system  that  is  about  tc  be  re  lea.  cd  to  a  customer,  such  testing  should  include  running  the 
testcases  in  the  regression  test  sune*  f again,  in  additional  10  normally  selected  testcases) 
The  precondition  for  this  special  operator  concern,  the  existence  of  a  goal  to  release  the 
system,  while  the  goal  5  .  rit.uiu  is  expressible  using  Joniam  ptedicates,  the  fact  that  a  goal 
with  this  formula  is  currently  instantiated  is  not  expressible  in  domain  terms  The  only 
recourse  is  to  write  separate  operators  with  artificially  different  goals  'Then,  operators  (like 
build)  that  have  testing  subgnaJs  will  be  affected.  Thu.,,  the  designer  of  the  operators  must 
produce  no'  only  a  rest  operator  and  a  ter.t-jor -release  operator,  but  also  a  normal 

build  operator  and  a  build  for -release  operator,  to  ensure  that  tire  right  type  of  testing  is 
performed  m  ail  cast  s 

Expressing  spec -dt  cave-  w  1  •  r.  this  brum  force  app'Oath.  already  attended  with 
disud  •  .0  :ar  cs,  or.-  ,h'  5 own  cnfi-ely  w  hen  mult. pin  special  cases  affect  a  single  operator, 
the  coribin.u,'"  s  me  mtoie-  hie  fiovn  um  designs* s  perspective  Special  cases  are  not 
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*  In  software  engineering,  regression  tc;.!i..g  s  peric  rm.ee  :■  er.sure  tra;  hugs  ha’- :  not 
been  •nir-.xiu-  ec  into  functions 'that  were  pre'io  usis  sr  w>  to  ■  ■  k  cooectly 


guaranteed  u-  be  simp’.y  additive  w-itn  respect  to  'tv 
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In  deab:  wu'-.  tec-r.cry  fr-.  m  opccXT  fell  ere,  there  ■ 
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:  -ircle  1  •■•■tc. au xn.  that  extends  me  represent?  ciona:  power  of  hierarchical 
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composed  from  meta-ievel  operators;.  These  operators  have  the  same  form  as  domam 
operators  (with  preconditions,  subgoais,  etc.),  bui  they  use  predicates  describing  plan 
networks,  as  well  as  domain  predicates. 


The  primary  advantage  of  this  method  is  expressive  completeness.  Any  aspect  of  an 
operator  definition  (such  as  preconditions,  subgoais,  constraints,  or  effects),  as  well  as  any 
aspect  of  an  operator  instance  (such  as  bindings  of  variables  or  ancestor  operator  instances) 
can  be  accessed  or  modified.  The  transformational  approach  also  addresses  the  problem  of 
providing  a  complete  library  of  operators.  Because  knowledge  of  exceptions  is  partitioned 
from  knowledge  of  normal  cases,  the  two  issues  can  be  tackled  separately.  The  process  of 
writing  operators  is  further  unproved  because  multiple  transformations  can  apply  to  a  single 
operator,  thereby  preventing  combinatorial  explosion  in  numbers  of  operators. 


3.0  Transformations  on  Plans 


Both  planning  and  plan  recognition  involve  building  a  complete  plan  network.  Normally 
each  action  applied  to  a  network  can  be  thought  of  as  taking  the  network  one  step  closer  to 
completeness.  In  contrast,  a  transformation  will  reformulate  the  current  state  of  the 
network,  with  the  effect  of  changing  the  solution  set  that  will  be  pursued  to  complete  the 
network.  Such  a  reformulation  is  necessary  either  because  the  existing  state  of  the  network 
does  not  accurately  reflect  special  circumstances  or  because  other  actions  have  reached  a 
dead  end  (for  example,  an  operator  in  the  plan  has  failed.)  Reformulating  the  network 
represents  a  permanently-  instantiated  objective  of  the  planner/recognizer.  Thus,  the 
execution  of  (top-level)  transformations  will  be  data-driven:  they  will  be  applied  whenever 
the  current  state  of  the  network  indicates  an  opportunity  to  do  so. 

3.1  Example:  A  Special  Case 

Software  development  is  an  example  of  a  domain  where  a  large  part  of  the  knowledge 
about  how  actions  are  carried  out  is  concerned  with  special  cases.  Consider  a 
transformation  that  implements  the  requirement  to  do  regression  testing  before  a  release. 
When  expressed  precisely,  the  transformation  affects  an  instance  of  test  occurring  as  part  of 
the  expansion  of  release  To  be  entirely  safe,  one  additional  restriction  should  be  given:  that 
the  system  being  tested  is  the  same  as  the  system  being  released.  This  will  allow  other 
testing  instances  to  occur  in  the  same  expansion  (such  as  running  a  testcase  to  help  decide 
a. ha:  editing  changes  arc  needed),  while  ensuring  that  regression  testing  is  required  on  the 
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3 2  Example:  Failure  Recover) 


Software  development  is  a  domain  uherc  there  are  many  causes  of  failure,  including 
system  problems,  rooi  problems  and  programmer  erro'-.  In  particular,  given  that  much 
work  is  carried  out  on  a  tnal-anti-error  basis,  failures  due  to  programmer  error  are  to  be 
expected  frequently.  Consider  the  case  of  the  link  operator  failing  to  produce  a  load 
module  because  errors  made  by  the  programme”  were  detected.  In  fact,  decisions  about 
recovery  from  this  failure  are  not  made  at  the  local  level  of  the  link  operator,  a  link  operator 
failure  implies  that  the  parent  operatot  has  failed,  and  the  appropriate  recovery  strategy  is 
dictated  by  what  that  parent  operator  is. 

The  parent  operator  will  usually  be  the  build  operator.  If  the  buiid  operator  has  failed  and 
the  system  that  was  built  is  faulty,  one  recovery  scenario  is  to  go  through  the  whole  build 
process  again:  but.  ms  lead  of  starting  from  the  same  baseline  used  in  the  original  build 
instance,  this  new  build  instance  will  start  with  the  faulty  system  as  the  baseline.  That  is, 
the  new  build  instantiation  will  use  as  the  binding  of  its  baseline  v-anable  the  binding  of  the 
system  variable  from  the  failed  build  instantiation. 

'These  strategies  can  be  expressed  m  two  separate  transformations.  The  first  transformation 
applies  to  instances  of  link  that  have  failed;  its  effect  is  simply  to  mark  the  parent  operator 
instance  as  foiled.  The  second  mm  s  forma  don  applies  to  instances  of  build  that  have  failed; 
its  effect  is  to  create  a  new  instantiation  of  the  build  operator,  and  to  fix  the  binding  of  the 
baseline  variable  in  that  instantiation  to  be  equal  to  the  bindmg  of  the  system  variable  from 
the  "superseded"  instantiation  of  build.  This  is  shown  in  Figure  5. 

33  Other  Examples 

The  software  domain  is  particularly  nch  in  opportunities  for  expressing  domain  knowledge 
in  transformations.  Some  additional  examples  are: 

•  In  a  multi-user  system,  when  the  number  of  users  logged-m  is  below  a 
certain  threshold,  then  commands  will  be  submitted  for  foreground 
execution  rather  than  lo  a  background  queue.  One  transformation,  applying 
to  all  operators  utilizing  the  background  queue,  can  be  written  in  lieu  of  an 
additional  version  of  each  such  operator. 
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Tlie  conservative  editing  style  of  frequer  A  :-v  •  r  snart'o:  of  the  file 
beirg  edited  also  involves  eventually  <ieV.:  :  1.  *  rmdicte  snapshots. 
This  too  is  a  complex  transformation,  became  *..?  deletions  cannot  be 
specified  until  after  the  identity  of  the  satisfviorv  version  is  known. 

Piognoimmcrs  generally  follow  a  set  of  rules  about  how  files  are  allocated  to 
directories.  However,  in  the  heat  of  activity,  a  file  may  be  created  in  the 
"wrong”  directory.  A  transformation  could  trigger  on  this  and  instantiate  a 
goal  to  move  the  file  to  the  proper  directory.  Such  transformations 
reestablish  desirable  domain  states,  in  the  manner  of  McDermott's  primitive 
policies  112). 

At-,  operation  copying  one  file  to  another  is  used  expressly  for  the  purpose 
of  preventing  conflicts  between  two  subsequent  actions,  one  of  which  will 
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modify  the  file  and  the  other  of  which  will  use  the  original  form  of  the  file. 
Copy  can  be  written  as  a  normal  domain  operator,  but  as  in  the  case  of 
operator  failure,  some  connection  still  remains  to  be  made  between  the  goal 
of  copy  and  a  situation  when  it  is  appropriate  to  instantiate  that  goal.  A 
transformation  can  be  written  to  do  this;  the  precondition  for  the 
transformation  is  that  an  adverse  interaction  between  two  planned  actions 
has  been  detected.  Here  a  transformation  is  used  to  augment  the  domain- 
independent  forms  of  untangling  operator  interactions  by  defining  a  domain- 
specific  strategy. 

*  A  well-established  strategy  for  dealing  with  the  compiler  having  blown  up 
when  directed  to  compile  at  its  highest  optimization  level  is  to  try  again  with 
optimization  turned  off.  If  this  results  in  a  successful  compilation,  the 
programmer  will  settle  for  a  load  module  which  is  only  partially  optimized, 
even  if  performance  testing  was  planned.  This  transformation  should  both 
rephrase  the  goal  to  lower  the  optimization  required  and  instantiate  a  goal  to 
repeat  the  performance  testing  when  a  fully  optimized  load  module  can  be 
produced.  This  is  an  instance  of  McDermott's  notion  of  rephrasing  a  goal 
when  no  plan  can  be  constructed  to  achieve  it. 

•  If  editing  a  source  module  consists  of  cosmetic  changes  only,  then  an 
alternative  to  recompilation  is  simply  to  acquire  (and  place  in  the  appropriate 
directory)  the  object  module  of  the  previous  version  (assuming  no  include 
modules  were  also  changed).  However,  it  is  bad  practice  to  do  this  on  a 
final  release  to  a  customer.  Only  by  expressing  this  in  a  transformation  can 
we  ensure  that  good  practice  is.  followed.  In  this  case  the  goal  is  rephrased 
to  take  advantage  of  special  circumstances. 


It  should  be  clear  from  the  foregoing  examples  that  the  transformations  are  operators  on  the 
state  of  planning;  these  meta-level  operators  are  combined  to  form  meta-plans. 
Procedurally-implemented  meta-plans  were  introduced  by  Stefik  [16]  to  pursue  control 
issues  in  planning.  Declarative  meta-plans  were  defined  by  Wilensky[18]  in  order  to  share 
knowledge  between  a  planner  and  a  plan  recognizer.  Neither  of  these  meta-plan  systems 
was  used  to  modify  operator  instances  by  adding  new  subgoals,  changing  constraints  and 
so  forth.  Meta-pians  that  could  modify  steps  or  change  parameter  bindings  were  defined 
for  a  natural  language  dialog  understanding  system[ll].  In  these  meta-plans,  the 
modifications  were  meta-plan  parameters  which  were  bound  from  information  in  the 


utterances. 


4.1  The  Meta-levd  State  Schema 


The  meta-level  state  schema  covers  most  of  the  internal  data  stu-c  ■  i~s  wd  ■:  planning. 
The  end  tv -relationship  (ER)  model  of  data  [4]  provides  a  use-  a.  way  io  visualize  such  a 
complex  state  schema.  In  the  ER  model,  there  are  entities,  w.nich  !  a«  attributes  and 
participate  in  relationships  with  other  entities.  There  is  ?  straijiv.fnrward  translation 
between  the  ER  model  and  predicate  calculus,  whereby  iSstionship4-  and  attributes 
correspond  to  predicates.  Semantic  constraints  can  be  expressed  a'  axioms  in  predicate 
calculus.  Other  axioms  can  be  used  to  define  additional  predicates  and  fo  define  appropriate 
functions. 

The  ER  diagram  of  the  meta-level  state  schem.3  is  given  in  Figu-.e  y.  The  objects  and 
relationships  shown  are  representative,  not  exhaustive.  1  re  schema  describes  operators  as 
they  are  defined  in  the  GRAPPLE  formalism,  and  addresses  the  reo;  irements  cf  plan 
recognition  (the  context  in  which  we  are  currently  implementing  the  /neta-pTns). 

The  state  schema  for  the  meta-plans  contains  objects  ana  predicates  organized  into  three 
subspaces:  operator  library,  plan  network,  and  the  domain  state  The  operator  library 
subspace  describes  all  components  (preconditions,  effects,  etc.)  of  all  operators,  and  their 
formulas  and  (static)  variable  names.  'The  plan  network  subspace  describes  the  hierarchy 
of  operator  instances:  their  dynamic  status  (started,  completed  failed...),  their  internal 
states  and  status  (pending,  achieved,  protected  Also  associated  with  operator  instances 
are  the  dynamic  name  scopes  and  variable  binding  infoimaton  reeded  v.>  evaluate  operator 
formulas.  The  domain  state  represents  the  truth  value  of  all  domain  f  educates.  Additional 
predicates  cross  subspace  boundaries,  relating  operator  instances  b:A  to  their  definitions, 
and  operator  instances  to  the  domain  predicates  'hey  affected 

The  state  schema  is  designed  so  that  it  represents  a  single  choice  from  among  the  competing 
interpretations  of  a  series  of  actions.  Thus,  if  an  operator  can  achieve  the  subgoals  of  two 
other  operators,  this  will  be  represented  using  two  states,  each  in  a  separate  context. 
During  recognition,  there  will  usually  be  multiple  contexts  that  are  active;  an  important 
component  of  the  recognizer  comprises  strategies  for  focusing  among  these  alternatives,  as 
well  as  for  selecting  the  operations  applied  to  an  alternative.  Thus  we  make  the  same 
distinction  as  in  [16]  between  operations  in  planning  space  and  the  control  strategies  by 
which  those  operations  are  selected.  The  transformational  meta-operators  add  to  the 
number  of  operators  subject  to  control  decisions. 
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42  Metaoperator  Constructs 

Because  the  transformation:  are  complex,  expressing  them  as  operators  requires  a  language 
engineered  for  ‘  real-world"  use  For  example,  effects  of  operators  must  be  able  to  create 
new  objects  (for  example,  a  new  subgoal  instance).  Some  transformations  (such  as  the  one 
to  delete  extraneous  files)  require  a  facility'  .'or  iterating  subgoals:  that  is,  for  repeatedly 
achieving  a  subgoa!  formula  over  a  set  of  bindings.  Conveniently,  all  the  needed  facilities 
were  already  aval 'able  in  the  formalism  we  designed  to  handle  the  complex  domains 
anticipated  for  GRAPPLE  [7],  No  new  facilities  (except  a  keyword  to  distinguish  between 
operators  and  meta-operators)  were  needed. 

The  transformation  for  regression  testing  before  release  is  shown  as  a  meta-operator 
(expressed  in  GRAPPLE  notation)  in  Figure  7.  This  wiil  be  a  top-level  operator  assuming 


{METAOPERATOR  r»gr**slon*-b«for*-rpl»a«»i- 


(GOAL  appll«d-to(r*gr»MO.i»-t)«)or»->-*irt ine'H-e  -p;.' 

(PRECOND  (STATIC  lr«t*ne*-o((?tSBt-op1!r,v)  AND 

■nc«»tor(?t«*t-op,?re!op.'  AND 
ti8tanc*-of(?rak3p.r*i«.i!fcM;  AND 
■■ma-dyruim  kxwr»(  sy^ton , » .-t  I -op . 

»yst*m,?t»*t-op) }  AND 
NOT  appIte<J-to(r«graaslDn»-S:ro  'r-'toiaass., 
?W*1-op)  )  ) 

(EFFECTS  (NEW  atata-lnsunca  ?r«yaaslons) 

(NEW  aubgoaLantry  ?ragr-auJ>goai' 

(NEW  Marat ion-so«c  ?!t#r«ta-lnto) 

(ADO  parl-of(?raciressbrt»,  ?ta3t-oD)l 
(ADD  instanca-of(?r£>g:a3£ior.s,  Vracr  s-boos  )) 
(ADD  Merator(?ragrsi.'bgojl,  v.,  a'p-h'o)’ 
(ADD  aourca(?raflr6.:^i''n';,  no-ap-ar1',. 

(ADD  role(?regre*si=ns>  a  :bg  j*l)) 

(ADD  protactkin(?rf3')a3(0";3,  n».-p'.Macu3.j 
(ADD  aatl8tacttoo(?ragr8as!on»>  unkn  jy..--)! 
(ADD  formula(?r«gr-sjbgM!. 

t»at0don('?sysurr^/ivzr~ca84))  } 

(ADD  foimuia(?St»r»t#-  Info. 

ln-ngrBssion~8u!t0{?r»gr-citne) )  ) 

(ADD  applled-to(rsgr«ssk>na-b«fora-ret3*.aa, 
?teat-op) ) )  ) 


that  its  goal  does  not  match  the  precondition  t  r  suhg^a)  of  other  m eta -operators;  therefore, 
it  will  be  executed  when  its  precondition  become?  c*ce  T  r.t  wiil  happen  when  there  is  an 
instance  of  test  whose  ancestor  is  an  instance  of  yeiec.se  AND  when  the  system  variables  of 
both  operators  correspond  (e.g.,  arc  mapped  to  the  same  dynamic  name).  The  precondition 
carries  the  keyword  STATIC,  meaning  that  no  explicit  attempt  should  be  made  to  render  it 
true. 


Performing  the  transformation  is  simply  a  matter  of  realizing  the  effects  of  the  meta¬ 
operator  in  this  case,  because  there  are  no  subgoals  to  be  achieved.  These  effects  are  all 
directed  at  creating  a  new  state  instance  as  part  of  the  test  operator  instance.  The  new  state 
instance  has  a  supporting  subgoal  entry  that  defines  the  state  formula  and,  since  it  is  an 
iterated  subgoal,  the  iteration  formula.  Note  that  the  meta-operator  contains  these  formulas 
explicitly;  they  consist  of  domain  predicates  and  variable  names  in  the  static  name  scope  of 
the  ’est  operator  definition.  After  the  transformation  has  been  executed,  the  precondition 


Figure  B: 


(MCTAOPERATOR  pnopagat®-Unk-fal!ur* 

GOAL  atatu^^.lnk-op.fallura-proceaa**!)) 

IPRECOND  (STATIC  status(?link-op,  fall®d)  AND 

instano^-o^Tli.ik-op.link)  AND 
query  f?iink-op,  1aulty(?syst»m)  )  )) 


(CONSTRAINTS  ^srer  v vLnK-op,?par»nt-op)) 

(EFFECTS  (DELETE  6tatus(?parent-op,ln-progr#M) ) 

(DELETE  statue  (?llnK-op,(alted) ) 

(ADD  a'.atus{?pareni-op, tailed)) 

(ADD  status(?llnk-op,tallure-proc»aaed)) )) 


will  no  longer  be  for  this  instance  of  test;  thus,  this  transformation  is  not  meant  to  be 
applied  more  than  once  to  the  same  situation. 

The  transformation  exporting  the  failure  of  the  link  operator  to  its  parent  operator  is  shown 
in  Figure  8,  to  show  how  a  goal  for  failure  recovery  is  expressed. 


5.Q  Status  usion 


A  plan-based  approach  to  intelligent  assistance  for  the  programming  process  appears  to  be 
an  appropriate  match  between  problem  and  solution  paradigm.  However,  it  is  dependent 
on  capturing  complex  domain  knowledge  in  operator  definitions.  Transformational  meta- 
plans  provide  a  means  of  overcoming  the  representational  limits  of  existing  plan 
formalisms.  Defining  domain  knowledge  about  special  cases  and  failure  recovery  via  meta¬ 
operators  provides  an  expressively  complete  approach,  which  obviates  the  need  for  special- 
purpose  language  extensions.  This  approach  also  expands  the  role  that  meta-planning 
plays  in  a  planning  architecture.  The  resulting  transformations  represent  a  special  class  of 
operations  on  plan  networks:  operations  that  reformulate  a  network  rather  than  solve  it  As 
an  additional  benefit,  this  approach  eases  the  writer’s  task  of  providing  thorough  coverage 
of  domain  actions. 


We  are  currently  implementing  the  transformations  as  pan  •>:  th*  GRT  '  L  plan 
recognizer.  This  implementation  uses  Knowledge  Craft™  and  capitalizes  or.  its  OciEues 
for  context  management,  object  schema,  and  integrated  Prolog  features  %--'c  ;  :  continuing 
to  explore  the  role  of  deeper  domain  knowledge  in  planning  systems,  witn  [.articular 
emphasis  on  a  deep  model  of  programming  process  kno  • •'  ;e  and  its  potential 
contributions  m  an  intelligent  assistant. 
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1  Objectives  of  the  Performance  Estimation  Assistant 

Hi  is  paper  will  report  on  the  plans  and  progress  toward  the  construction  of  prototype  Performance 
Estimation  Assistant  t  PL  A  :  I  he  objectives  of  the  PEA  is  clearly  stated  in  the  KBSA  report  2 
We  include  the  relevant  section  from  that  report. 

The  long-term  goal  of  the  performance  facet  is  to  help  to  create  and  maintain  efficient 
programs  that  meet  their  performance  requirements.  Theperformance  facet  will  guide 
performance  decisions  at  many  levels  from  requirements  specifications  to  very-high 
level  programs  to  low-level  code.  Performance  assistance  capabilities  are  critical  for 
making  practical  tools  of  very-high-level,  executable  specification  languages.  Because 
the  key  disadvantage  of  such  specifications  is  their  lack  of  efficiency  when  executed 
straightforwardly,  the  important  iactor  ;n  their  utility  is  being  able  to  find  efficient  im¬ 
plementations.  During  development,  efficiency  estimation  will  be  used  to  predict  and 
compare  the  costs  of  proposed  alternative  data  structure  choices.  With  this  capability 
eithei  a  programmer  or  an  automated  program  synthesizer  can  select  a  data  structure. 

KBSA  will  also  give  performance  advice  about  what  control  structures  to  use.  what 
optimizing  transformat  ions  to  apply,  and  what  algorithms  to  use.  Thus,  program  anal¬ 
ysis  includes  not  only  data  flow  and  control  flow  analysis,  but  also  higher-level  analysis, 
such  as  algorithm  analysis,  to  determine  the  time  and  space  efficiency  of  programs,  to 
suggest  modular' zar.ons,  and  to  find  bottlenecks.  It  also  involves  augmenting  appli¬ 
cation  domain  models  to  include  some  cost  information.  At  the  requirements  level, 
advice  wiil  be  given  about  the  relative  costs  of  different  proposed  features. 

’This  research  was  supported  by  the  Rome  Air  Development  Center  (RADC)  under  contract  F30602-S6-C-0026 
The  views  and  conclusions  contained  in  this  paper  arc-  those  of  the  authors  and  should  not  be  interpreted  as 
representing  the  official  policies,  either  expressed  or  implied  of  RADC  or  the  U  S  Government 
D801  Page  Mil!  Road,  Palo  Alto,  CA  9*1304 


We  can  see  from  this  description  that  the  primary  function  of  a  PEA  :s  fo  select  among  alternative 
implementations  of  a  specification.  Thus  it  must  be  closely  coupied  witn  t he  development  tacet. 
which  generates  these  alternative  implementations.  Although  one  can  imagine  building  a  PEA 
which  is  in  some  sense  generic,  in  that  it  does  not  depend  at  all  on  the  generator,  i.e  a  specific 
language  and  associated  transformations,  this  will  not  be  the  an  preach  we  take.  Our  work  has 
indicated  that  a  useful  PEA  must  embody  knowledge  of  the  space  being  searched,  as  do  heuristic 
functions  which  control  the  search  in  classical  AI  problems.  Thus  the  prototype  PEA  is  specialized 
to  a  particular  development  task,  data  structure  selection.  This  consistent  with  the  short-term 
goal?  described  in  the  report.  Two  of  three  short-term  goals  are  (again  quoting  from  [2]): 


Symbolic  Evaluation  Symbolic  evaluation  is  a  basic  analysis  tecnnique  that  is  userui 
in  many  of  the  KBSA  facets  described.  However,  it  is  crucial  for  the  performance 
facet.  The  performance  facet  needs  to  be  able  to  propagat  e  and  integrate  efficiency 
estimations  and  to  perform  symbolic  analysis  on  partial  specifications. 

Data  Structure  Analysis  and  Advice  A  short-term  target  for  the  performance 
facet  will  be  a  set  of  estimators  for  data  structure  selection  that  are  reasonably 
robust  when  handling  conventional  data  structures  (probably  excluding  external 
memory  devices).  These  estimations  could  be  used  for  automatic  data  structure 
selection  or  for  advice  to  manual  implementors.  Efficiency  estimation  activities 
will  be  limited  to  those  necessary  for  data  structure  selection,  including  the  use 
of  both  rules  of  thumb  and  heuristic  algorithm  analysis.  As  an  initial  target,  ef¬ 
ficiency  estimation  will  provide  approximate,  average-case  performance  analysis. 
The  agents  will  compute  and  transform  annotations  about  efficiency  characteris¬ 
tics  as  programs  are  transformed,  and  will  record  cost  analysis  decisions  for  the 
benefit  of  future  users.  Some  bottleneck  finding  also  should  be  feasible  in  the 
short  term;  it  is  valuable  for  both  automated  and  manual  systems,  and  is  a  fairly 
straightforward  extension  of  the  basic  performance  analysis  capability.  By  limit¬ 
ing  the  performance  facet  initially  to  data  structure  selection  advice,  we  take  a 
conservative  position  and  increase  the  likelihood  of  success.  It  may  be  necessary, 
if  certain  applications  are  undertaken,  to  include  other  optimization  decisions. 


firm  first  of  these  items  is  a  method  of  analysis,  the  second  specific  functionality.  We  are  using 
a  symbolic  evaluation  capability  to  assist  data  structure  selection,  and  designing  the  symbolic 
evaluation  package  in  a  reusable  way.  Thus  when  more  sophisticated  PEA's  are  constructed,  this 
package  will  not  have  to  be  rewritten. 

Specifically,  data  structure  selection  is  the  selection  of  of  efficient  ADA-level  represerrut:  >::■■  • 
theoretic  data  types.  Finding  efficient  representations  for  set-theoretic  data  types  ••:.  c  . 
pertormance  estimation  problem  because: 

•  Tin-re  is  high  iikeiybood  of  integration  of  this  system  with  other  K  : t "  \  '  i  ■ 

•  It  :.s  intrinsically  an  important  problem  to  mi’iv**.  Tim  >  '  ■. 

about  programming.  For  example.  univer*rv  > 


•  A  generator  for  the  space  of  data  structure  implementations  exists.  This  is  one  of  the  few 
problems  for  which  a  good  generator  of  alternative  implementations  exist. 

As  part  of  the  project  an  initial  prototype  data  structure  selector  has  been  constructed.  It  has 
provided  evidence  that  good  results  will  emerge  from  this  project. 


2  Approaches  to  Performance  Estimation 

The  development  of  code  from  specifications  car.  be  simply  modeled  by  a  tree  structure  where  nodes 
represent  partially  implemented  specifications  and  arcs  represent  transformations.  Paths  through 
the  tree  represent  derivations  where  the  final  nodes  represent  executable  target- language  programs. 
A  crucial  role  of  the  PEA  is  help  guide  the  search  through  this  tree.  The  alternative  programs 
that  can  be  derived  are  dist  inguished  mainly  on  the  the  basis  of  their  resource  consumption — they 
all  implement  the  same  functionality  (since  transformations  are  correctness-preserving). 

The  PEA  must,  perform  analysis  of  the  program  to  guide  the  search.  This  analysis,  in  its  details 
depend  on  the  specific  form  of  specifications  and  programs  as  well  as  the  specific  generator  for  the 
space.  For  example,  because  functional  programming  languages  have  clean,  theoretical  properties, 
such  as  referential  transparency,  and  no  notion  of  control  flow,  performance  analysis  is  simplified 
in  this  context.  In  the  next  section  we  will  provide  specific  details  of  the  generator  and  the  specific 
analysis  requirements.  Generally,  we  are  able  to  classify  approaches  to  this  analysis  that  is  not 
specific  to  the  generator  employed.  Briefly  they  are:  the  qualitative  approach,  symbolic  approach, 
simulation- based  approach  and  the  statistical  approach.  The  reader  is  referred  to  the  accompanving 
paper  in  this  volume  for  more  detail.  The  PEA  we  are  building  will  utilize  the  qualitative  and 
symbolic  approaches. 


3  The  Generator 

In  this  section  we  first  describe  the  generator  that  the  PEA  will  use  by  describing  the  specification 
and  programming  language  and  the  transformation  rules  which  generate  the  space  of  alternative 
implementations  for  the  language  The  goal  cr  this  work  is  to  produce  a  PEA.  but  as  explained 
above,  the  tight  interaction  between  development  and  performance  requires  that  a  specific  gen¬ 
erator  be  used.  Our  approach  is  to  incorporate  an  existing  generator  into  the  delivered  system. 
Thus  we  will  minimize  effort  not  directed  specifically  at  performance  estimation. 

The  specification  language,  which  is  called  PERFORMG,  is  a  functional  language  with  high-level 
set-theoretic  data  types.  Our  intention  is  not  to  produce  a  polished,  practical  language;  that  is 
a  distraction  from  the  goals  of  our  work.  Rather  the  language  provides  a  minimal  framework 
on  which  to  construct  a  data  structure  selector.  The  transformation  rules  apply  to  the  data 
structures  of  the  program  only,  and  will  be  directed  by  the  PEA  to  select  efficient,  ADA-level 
data  type  implementations.  The  object  program  will  remain  at  the  functional  level  That  is,  we 
are  not  concerned  with  control  structure  optimizations,  such  as  recursion-to-iteration  constructs. 


The  advantage  treating  the  data  structure  selection  problem  in  a  functional  context  is  that  the 
analysis  on  which  data  structure  choices  are  made  is  greatly  facilitated  because  ot  the  referential 
transparency  of  declarative-level  forms.  Generally  assertions  about  program  properties  that  are 
true  universally,  rather  than  true  at  certain  program  points  can  be  inferred  w-thout  the  need  for 
elaborate  control  flow  analysis.  The  analysis  techniques  developed  oouid  be  extended  to  work  on 
imperative  programs  if  desired.  The  data  structure  selection  is  based  on  an  analysis  local  to  each 
function  definition.  This  restriction  can  be  removed  in  a  larger-scale  prototype. 

3.1  PERFORMO 

PERFORMO  is  a  single- assignment,  functional  language.  Other  languages  of  this  variety  are  VAL 
[3],  developed  at  MIT,  and  SISAL  [4],  developed  at  Lawrence- Livermore  Lab.  In  such  a  language 
each  “variable”  is  defined  by  an  equation  which  is  computed  only  once  (hence  <,be  notion  of  single 
assignment).  These  language  preserve  the  referential  transparency  that  enhances  the  analyzability 
of  functional  languages,  while  providing  a  convenient  syntax. 

Unlike  other  functional  languages  which  primarily  rely  on  lists  as  the  fundamental  data  type, 
PERFORMO  provides  very-high-level,  set-theoretic  Data  types  and  lower-level  data  types  which 
the  set-theoretic  types  are  refined  into.  Another  notable  feature  of  PERFORMO  is  its  flexible 
iteration  constructs,  which  are  useful  for  refining  many  of  the  operations  defined  on  set- theoretic 
objects.  Many  operations  which  are  implemented  by  explicit  recursive  cails  in  functional  languages 
without  this  construct  can  be  more  simply  implemented  by  the  iteration  construct. 

3.1.1  The  Data  types 

PEPcFORMO  is  strongly-typed  and  provides  set-theoretic  type  constructors.  As  part  of  a  declara¬ 
tion  the  user  may  specify  assertions  about  the  defined  data  objects.  These  assertions  can  be  used 
to  define  sub-types,  provide  information  as  to  the  maximum  size  of  the  data  objects,  and  other 
properties.  These  assertions  provide  information  that  is  used  by  the  PEA  to  select  implementa¬ 
tions.  At  the  same  time  these  assertions  provide  a  natural,  high-level  specification  capability  to 
the  user.  For  example,  the  type  map  integer  to  integer  may  be  restricted  to  map  S  to  integer  where 
S  is  a  subset  of  the  integers  defined  assertionally  in  the  program.  As  we  shall  see,  this  assertion  is 
supplying  containment  information  which  is  basic  analysis  data  for  data  structure  selection. 

The  Base  Types  The  base  data  types  of  the  language  are  integer,  real,  Boolean,  char,  and 
atom.  The  usual  operations  are  defined  on  these  types.  In  particular,  an  if-then-else  construct  is 
defined. 

The  Composite  Types  The  composite  types  are  sets,  maps,  sequences,  products,  and  rela 
tions.  Thus  the  types  provided  are  similar  to  those  in  REFINE,  SETL  [6]  and  AP5[lj.  An 
important  difference  however,  is  that  the  notion  of  a  normal  form  is  introduced.  Programs  may 
be  written  using  a  large  collection  of  useful  operations  on  these  types,  but  the  programs  will  be 


mechanically  transformed  into  programs  using  just  a  few  operations.  Such  programs  are  said  to  be 
in  normal  form.  Our  analysis  capabilities  are  based  on  programs  in  this  restricted  form,  providing 
an  important  simplification. 

We  briefly  review  the  operations  in  the  normal  form  language.  The  operations  found  in  the  above 
mentioned  languages  can  be  easily  expressed  m  terms  of  these  primitives.  Many  of  the  powerful 
operations  on  composite  objects,  such  as  reduction  operations,  quantification,  and  set-formers 
require  iteration  over  a  composite  structure  to  implement.  The  language  contains  one  general 
form  of  iteration  called  a  generator  expression  Ii-  the  normal  form  all  these  familiar  operations 
are  reduced  to  generators.  The  syntax  of  generators  will  not  be  given  here,  but  reserved  for  the 
complete  language  description. 

Sets  Sets  are  unordered  collections  of  non-repeating  elements.  The  operations  on  sets  are:  ex¬ 
plicit  set  former  (create  a  set  with  the  specified  elements),  less  (create  a  set  from  a  given  set  with 
one  element  removed),  with  (create  a  set  from  a  given  set  with  an  additional  element  inserted), 
arb  (choose  an  •"lement  randomly  from  a  set),  6  (a  predicate  which  tests  set  membership),  and 
union  (form  the  union  of  two  sets). 

Maps  Maps  associate  with  elements  in  a  domain  set,  elements  from  a  range  set.  The  operations 
on  sets  are:  lambda  definition  (define  a  map  with  a  lambda  definition),  domain  (return  the  set 
composed  of  the  domain  of  the  map),  range  (return  the  set  composed  of  the  range  of  the  map), 
and  application  (compute  the  range  element  corresponding  to  a  given  domain  element). 

Sequences  Sequences  are  ordered  collections  of  elements.  The  operations  are:  explicit  sequence 
former  (which  creates  a  sequence  out  of  the  given  elements),  6  (a  predicate  which  tests  membership 
in  a  sequence),  indexed  retrieval  (returns  the  element  at  a  specified  position  in  a  sequence),  and 
insertion. 

Products  Products  are  like  Pascal  records.  The  operations  are  product  formation  and  compo¬ 
nent  selection. 

Relations  Relations  are  simply  sets  of  products.  Thus  all  the  set  operations  may  be  applied  to 
relations  as  well  as  projection  along  any  component. 

3.1.2  Function  Definitions 

A  functional  program  in  a  single-assignment  language  consists  of  function  definitions  composed 
of  a  header  which  defines  the  input  parameters  and  the  output  value  of  the  function  and  a  body 
consisting  of  declarations,  assertions  and  defining  equation?  for  each  variable  in  the  function.  We 
cal!  these  equations  definitions. 


3.2  Refinement  Rules 


The  generator  of  the  space  of  data  structure  implementations  are  caUed  refinement  rules  A 
refinement  is  a  collection  of  rules  that  refine  the  variable  declaration  of  an  ooject  along  with  all 
operations  performed  on  the  object.  Refinements  are  designed  so  that  the)  may  be  composed 
together  in  order  to  create  the  implementation  of  the  variable.  This  allows  a  siepwise  refinement 
approach  to  data  structure  selection. 

Here,  briefly  is  a  description  of  some  of  the  refinements  used  in  the  PEA. 


set-to-sequence  A  set  of  objects  is  represented  as  a  sequence  of  those  objects.  Each  object  ap¬ 
pears  in  the  sequence  once  and  the  order  is  arbitrary.  Implementations  based  on  maintaining 
the  sequence  in  sorted  order  are  not  considered. 

set-to-characteristic-function  A  set  is  represented  by  a  total  map  from  some  superset  of  its 
domain  to  Boolean.  The  superset  must  be  specified  in  the  rule  <  r»j  fixation  and  must  be  a 
variable  that  appears  in  the  program  or  an  integer  (or  character)  subrange. 


map-to-array  A  map  from  an  integer  or  character  subrange  is  represented  as  an  array. 

map-to-field-of-product  Applies  only  to  an  non-parameterized  object,  that  is,  one  for  which 
there  is  only  one  instance  of  the  map.  An  example  of  a  parameterized  object  is  the  type  of 
elements  of  the  range  of  a  map.  There  is  one  such  element  for  each  domain  element  of  the 
map.  Furthermore  the  product  must  represent  a  set  which  is  a  superset  of  the  domain. 

map-to-relation  A  map  is  represented  by  its  graph. 

seq-to-list  A  sequence  is  represented  as  a  list. 

seq-to-map  A  sequence  is  represented  as  a  map  front  an  integer  subrange  to  the  element  type  of 
the  sequence. 

relation-to-map  A  relation  is  represented  as  a  map  from  one  of  its  fields  to  a  set  of  tuples  of 
the  remaining  fields. 

relation-to-set-of-product  The  relation  is  stored  as  a  set  of  products. 

object-to-accessor  An  object  here  is  a  variable  of  any  type,  including  integers,  reals,  Booleans. 
We  require  a  base  set  S  such  that  the  object  is  an  element  of  the  base.  Furthermore  S  must 
be  represented  so  that  a  pointer  or  array  reference  accesses  its  elements. 

accessor-to-pointer  Access  is  via  a  pointer. 

accessor-to-integer-subrange  Access  is  via  an  array  index. 

We  illustrate  how  these  refinement  rules  can  be  composed  together  to  implement  a  set-theoretic 
data  type  at  the  ADA  level.  Suppose  that  a  variable  of  type  map  appears  in  a  program.  Using 
the  refinement  map-to-relation  the  variable  may  be  refined  into  a  relation.  Using  relation-to- 
set-c  f- prodw ' ,  the  relation  may  be  represented  as  a  set  of  products.  The  set  may  may  then  be 


represented  as  a  list  using  the  refinement  set  -to-list.  Note  each  time  a  refinement  is  used  operations 
are  refined  as  well.  For  example,  if  the  operation  ‘domain’,  was  applied  to  the  original  variable 
then  this  operation  will  be  refined  into  code  which  enumerates  the  list,  extracts  the  first  element 
of  each  product  and  collects  them  into  a  set. 

Notice  that  other  refinement  paths  are  possible,  leading  to  a  tree-shaped  space  of  possible  imple¬ 
mentations.  The  PEA  must  select  the  refinement  path  that  leads  to  an  efficient  representation. 


4  The  Performance  Estimator 


The  PEA  can  be  broken  into  two  parts.  The  first  part  is  called  the  analyzer ,  the  second  the 
selector.  The  analyzer  is  responsible  for  collecting  information  which  will  provide  the  basis  for 
the  decision  making  by  the  selector.  The  source  of  this  data  is  the  program,  and  annotations 
(assertions)  in  the  program  written  by  the  user. 

One  advantage  of  working  in  the  domain  of  data  structure  selection  is  the  existence  of  criteria 
for  determining  when  an  efficient  representation  has  been  achieved.  Namely,  we  strive  for  simple 
representations  in  which  every  data  structure  operation  is  implemented  by  its  theoretic  lower- 
bound.  For  example  we  insist  that  map  application  be  performed  in  constant  time  and  that 
enumerations  of  a  set  take  time  proportional  to  its  size.  Since  our  generator  can  only  generate 
relatively  simple  structures,  the  constant  factors  associated  with  these  operations  will  be  low. 
For  example  hash  table  representations  are  not  included  because  hashing  while  constant  time  (on 
average)  is  too  complex  to  be  efficient.  If  all  operations  are  implemented  within  its  theoretic  lower 
bound  then  the  data  structure  selector  has  succeeded  in  finding  the  best  possible  implementation. 
Furthermore,  the  system  can  report  that  the  best  implementation  has  been  found.  Often  this  is 
possible. 


4.1  Analysis 


The  data  collected  by  the  analyzer  is  both  of  a  qualitative  and  quantitative  nature,  used  for  quali¬ 
tative  performance  estimation  and  symbolic  performance  estimation ,  respectively.  The  qualitative 
analysis  will  be  sophisticated,  similar  to  the  analysis  that  an  optimizing  compiler  performs. 

The  analysis  data  is  derived  by  inspection  (of  the  program  and  user-supplied  assertions),  symbolic 
evaluation,  and  inference.  As  an  example  of  the  use  of  inference  suppose  the  size  of  a  a  set  5  is 
known  to  be  n,  f  to  be  a  one-one  function  and  T  is  defined  by  the  equation  T  —  {f(s)  :  s  €  Sj,  then 
the  size  of  T  can  be  inferred  to  be  n.  Inference  of  this  variety  is  easily  expressed  as  transformation 
rules  in  REFINE,  the  system  used  to  construct  the  PEA.  The  inference  needs  of  the  system  are 
being  restricted  so  that  a  forward  inference  strategy  will  be  efficient. 

Below  we  summarize  the  kinds  of  analysis  that  will  be  performed,  and  indicate  the  technique  used 
for  the  analysis. 
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4.1.1  Type  Analysis 
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The  language  is  strongly  typed.  A  Milner-style  type  checker/analyzer  a ;  utilized  in  ML,  REFINE 
and  other  languages  will  be  employed.  The  construction  of  such  a  checker  :s  well  understood.  This 
is  done  by  inspection  and  inference  (if  the  system  infers  types  from  context) 


4.1.2  Containment  Analysis 


This  refers  to  deducing  subset  and  membership  relations  among  the  data  objects  of  the  program. 
We  will  also  determine  whether  sets  are  disjoint  as  part  of  this  analysis  This  is  done  by  symbolic 
evaluation. 


4.1.3  Operation  Analysis 


Examine  each  use  of  a  variable  and  determine  what  operations  are  performed  on  the  variable. 
Data  structures  are  selected  to  support  efficient  implementation  of  those  operations  which  actually 
appear  in  the  program.  This  is  done  by  inspection. 


4.1.4  One-one  Analysis 


One-one  analysis  seeks  to  determine  if  elements  of  sequences  are  unique  and  whether  functions  and 
relations  are  one-one.  A  fundamental  issue  in  data  structure  selection  is  to  support  constant-time 
access  to  an  element  of  a  composite  data  structure.  This  is  often  difficult,  and  so  a  strategy  of 
optimizing  away  the  need  for  such  access  is  important.  For  example  when  a  value  is  inserted  into 
a  set  a  check  whether  the  value  is  already  in  the  set  is  required  If  this  check  can  be  proven  to  be 
unnecessary  more  efficient  can  can  be  generated.  One  application  of  one-one  analysis  is  to  remove 
such  checks  and  hence  ease  the  task  of  the  data  structure  selector.  This  is  done  by  inspection  and 
inference. 


Related,  but  not  nearly  as  useful  is  few-to  one  analysis.  A  map  is  few-to-one  if  only  a  constant 
number  of  domain  elements  map  to  the  same  range  element.  This  information  is  useful  for  symbolic 
analysis  of  variable  sizes. 


4.1.5  Symbolic  Analysis 


In  this  analysis  we  first  develop  symbolic  expressions  that  estimate  the  size  of  composite-valued 
variables.  This  information  is  then  used  to  compute  operator  frequencies  and  ultimately  complex¬ 
ity  estimates  on  the  time  and  space  requirements  of  an  implementation. 


The  analysis  starts  by  assigning  a  symbolic  variable  to  represent  the  size  of  each  composite  input 
value  Integer-valued  program  variables  may  also  appear  in  these  symbolic  expressions.  The  user 
has  the  option  of  specifying  a  maximum  bound  on  the  size  of  an  input  variable,  and  then  this 


constant  will  be  used  instead.  Then  using  the  definitions  of  non-input  variables  given  by  the 
program  this  size  information  is  propagated.  The  above  described  qualitative  analysis  aids  this 
process,  especially  one-one  and  containment  analysis.  There  are  difficult  technical  issues  that  must 
be  faced  in  deriving  these  estimates,  which  were  considered  in  [5] 

Given  variable  sizes  we  can  estimate  operation  frequencies.  Then  if  it  is  impossible  to  find  a  data 
structure  representation  that  efficiently  implements  two  operations  both  being  performed  on  the 
same  variable,  these  frequencies  can  be  used  to  decide  which  operation  should  get  the  efficient 
implementation. 

4.2  Selection 

The  fundamental  difficulty  of  choosing  data  structures  is  to  insure  that  element  tests  for  sets  and 
application  for  maps  is  performed  in  constant  time.  This  is  not  achieved  if  a  set  is  represented  as  a 
list.  To  test  if  an  element  is  in  a  list  the  whole  list  must  be  searched,  which  takes  time  proportional 
to  the  size  of  the  list.  Similarly  if  a  map  is  represented  as  a  list  of  domain-range  pairs,  a  similar 
search  must  be  performed  when  applying  a  map  to  an  domain  element.  However,  suppose  a  set 
is  known  to  be  a  subset  of  an  integer  subrange,  for  example  A  C  {1,2, ... ,  100}.  The  A  may  be 
represented  as  a  bit-vector,  i.e.  an  array  indexed  by  1..100  of  boolean  values  with  the  property 
that  the  ith  element  of  the  array  is  true  if  and  only  if  i  6  A.  This  will  provide  constant  time 
element  tests  for  A.  but  is  restricted  to  subsets  of  integer  subranges.  This  idea  can  be  extended.. 
Suppose  our  analysis  reports  that  A  C  B  and  that  x  €  B.  We  need  to  test  if  x  6  A.  Then  we  may 
represent  A  as  an  additional  Boolean-valued  field  in  a  product  representing  elements  of  B  with  the 
property  that  the  Boolean  is  true  if  the  element  happens  to  be  in  A  as  well,  x  is  represented  as  a 
pointer  to  elements  of  B.  To  test  if  x  €  B  just  follow  the  pointer  x  to  the  product  representing  the 
element  and  check  the  bit  indicating  whether  the  element  is  in  A.  This  can  be  done  in  constant 
time.  This  is  the  basis  of  the  data  structure  representations  in  the  SETL  compiler.  Some  of  the 
analysis  done  by  the  PEA  is  to  detect  subset  and  element  information  (containment  analysis)  that 
is  needed  for  selecting  these  implementations.  This  illustrates  just  one  of  the  complexities  of  data 
structure  selection.  Others  are  dealt  with  by  the  PEA,  for  example  minimizing  the  need  to  convert 
data  representations  in  different  portions  of  the  program. 

5  Implementation  Status 

The  implementation  of  the  PEA  is  progressing  using  version  2.0  of  the  REFINE  system.  Currently, 
the  designs  of  most  components  are  complete.  The  language  can  be  parsed  and  its  abstract  syntax 
is  defined.  Analysis  techniques  have  been  design  and  are  currently  being  implemented.  Data 
structure  refinement  rules  have  been  written.  Remaining  is  the  design  and  implementation  of  the 
selector  itself,  which  will  generalize  the  data  structure  selector  used  in  our  first  prototype. 
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6  Future  Work 


In  the  present  PEA  a  functional  program  written  using  high-level  data  types  is  transformed  into 
a  functional  program  operating  on  the  low-level  data  type  implementations.  In  our  future  work 
we  will  transform  the  control  structures  as  well  into  low-level  procedural  code.  The  framework 
we  have  described  will  accommodate  this  extension.  The  enhanced  prototype  would  incorporate 
efficiency  knowledge  in  the  following  areas: 


Finite  Differencing  Finite  differencing  is  an  important  optimization  that  can  lead  to  asymptotic 
improvements  in  program  efficiency. 

Proceduralization  This  is  the  application  of  subroutine  and  module  decomposition  device. 

Algorithm  Design  Advice  In  particular  the  capability  for  constructing  symbolic  efficiency  esti¬ 
mates  of  recursive  programs  will  be  established.  This  will  require  construction  of  a  recurrence 
relation  solver. 

Reformulation  Efficiency  estimates  can  be  used  to  guide  transforms  that  redefine  object  def¬ 
initions  into  an  equivalent,  but  perhaps  more  efficient  form.  An  important  class  of  these 
reformulations  implement  store-vs-compute  decisions. 

Loop  Fusion  Operations  over  set-theoretic,  composite  objects  are  implemented  with  extensive 
use  of  iteration.  These  loops  can  often  be  combined  to  yield  a  more  efficient  program.  We 
have  extensively  studied  this  optimization.  The  use  of  PERFORMO’s  iteration  construct 
support  the  expression  of  loop  combining  transformations. 
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Designing  an  Effective  User  Interface  for  a 
Knowledge-Based  Development 
Environment 
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Abstract 

One  of  the  chief  factors  in  the  success  of  transferring  Knowledge- Based  Software 
Assistant  (KBSA)  technology  to  industry  will  be  the  ability  of  users  to  interact 
efficiently  and  effectively  with  the  KBSA  system.  As  a  result,  KBSA’s  User  in¬ 
terface  must  be  carefully  designed  to  provide  a  wide  variety  of  users  with  easy 
access  to  a  wide  variety  of  information.  This  paper  desc -ibes  design  issues  of  an 
effective  interface,  its  required  functionality,  and  possible  approaches  to  providing 
that  functionality. 

1  Introduction 

An  effective  User  Interface  (U  'I)  plays  a  crucial  role  in  any  system.  This 
is  especially  true  of  the  Knowledge-Based  Software  Assistant  (KBSA).  Be¬ 
cause  of  the  wide  range  and  amount  of  available  information  and  the  varying 
degrees  of  user  sophistication,  a  powerful  and  flexible  U/I  will  be  critical 
in  the  acceptance  and  success  the  KBSA.  The  KBSA  knowledge  base  will 
contain  project  management  information  such  as  schedules,  available  re¬ 
sources.  resource  allocation,  costing  data,  project  structure,  and  policy. 
It  will  contain  technical  information  such  as  requirements,  specifications, 
code,  test  data,  and  test  results,  as  well  as  information  about  the  KBSA 
itself.  KBSA  users  will  span  the  spectrum  from  the  technically  expert  to 
technically  naive.  The  KBSA  must  accomodate  each  kind  of  user's  request 
for  whatever  type  of  assistance,  access,  or  information  they  require.  There 
appear  to  be  at  least  five  areas  in  which  the  U/I  will  play  a  role: 

1.  Runtime  support, 

2.  PMA, 

3.  Help/Tutor, 

4.  Query, 

5.  Inspection. 


First,  we  will  consider  the  design  guidelines  for  constructing  an  effective 
U  I.  Then,  we  will  consider  possible  approaches  for  providing  the  function¬ 
ality  of  the  above  five  U  I  areas  with  respect  to  the  attributes  of  an  effective 
U  I. 

2  Designing  an  Effective  User  Interface 

An  effective  U  I.  like  any  well  designed  system,  should  be  based  on  sound 
principles  or  standards.  Following  such  standards  provide  at  least  three 
benefits: 

1.  Better  interface  designs. 

2.  Increased  consistency  across  various  systems, 

3.  Reduced  cost  in  system  implementation. 

Although  much  progress  has  been  made  towards  defining  these  stan¬ 
dards  |9  ,  a  definitive  set  of  U/I  standards  is  still  a  long  way  off  [8j.  How¬ 
ever.  even  though  we  currently  lack  standards,  many  attributes  have  been 
identified  that  are  fundamental  to  an  effective  interface  ill, 17, 19,. 

2.1  Desirable  User  Interface  Attributes 

First,  the  interface  should  provide  consistent  and  intuitive  access  to  the 
system.  As  users  interact  with  the  KBS  A,  they  will  do  so  primarily  by 
applying  methods  to  objects.  They  will  edit  objects,  compile  objects,  se¬ 
lect  tasks,  etc.  A  consistent  interface  will  enforce  certain  restrictions.  If  a 
method  is  applicable  to  various  objects,  then  the  manner  in  which  it  is  ap¬ 
plied  will  be  the  same  for  all  objects  in  all  situations.  For  example,  suppose 
users  can  edit  both  requirements  and  specification  objects.  It  is  inconsis¬ 
tent  for  the  requirements  editor  to  be  invoked  via  a  command  line  interface 
while  the  specification  editor  is  invoked  via  mouse  selection.  Further,  in¬ 
teraction  with  the  editor  should  be  consistent  in  both  cases.  Deleting  a 
line  or  moving  text  should  appear  the  same  whether  editing  requirements 
or  specifications.  Help  and  query  facilities  providing  accurate,  up-to-date 
information  should  also  be  consistently  available.  For  example,  a  help  fa¬ 
cility  could  be  available  to  users  at  any  time  by  pressing  a  “HELP"  key. 
After  requesting  help,  users  can  ask  assistance  on  any  topic(s),  then  return 
to  whatever  task  they  were  performing  prior  to  requesting  help.  Such  con¬ 
sistency  will  play  a  big  role  in  the  interface's  intuitiveness.  An  intuitive 
U  I  allows  users  to  accomplish  tasks  in  “natural’*  ways,  by  asking  them¬ 
selves  “how  would  I  like  to  tell  the  computer  what  I  wantor.  Given  an 
intuitive  U  I  users  usually  would  be  able  to  correctly  guess  the  thing  to  do. 
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For  example,  it  is  more  intuitive  to  say  “EDIT  filename"  than  “IN\  '.)KE 
SYS. EDITOR  filename". 

Second,  the  interface  should  be  friendly  1]  .  That  is.  :t  should  pro¬ 
vide  unobtrusive  access  to  the  system  which  puts  users  at  ease.  Such  an 
interface  must  be  cooperative,  preventive,  and  conducive.  A  cooperative 
interface  actively  assists  users  by  keeping  them  aware  of  basic  capabilities, 
allowing  them  to  explore  additional  capabilities  easily,  and  keeping  them 
informed  on  what  the  system  is  doing  on  their  behalf  and  what  progress 
is  being  made.  A  cooperative  interface  will  also  allow  users  to  suspend 
tasks  and  quickly  return  to  them  at  some  later  time.  A  preventive  interface 
must  be  designed  to  expect  mistakes,  make  allowances  for  mistakes,  and 
allow  users  to  easily  recover  from  mistakes.  Finally  a  conducive  interface 
should  be  reliable,  predictable,  and  it  should  encourage  ussrs  to  explore 
new  capabilities  without  fear  of  irretrievably  destroying  ”’.*?/!  ^formation. 

Third,  the  interface  should  provide  access  to  Intelligent  help  and  query 
facilities  17  .  Studies  have  shown  that  such  on-line  assistance  can  substan¬ 
tially  affect  a  system’s  effectiveness,  usability,  and  W-..- .lability.  Users  re¬ 
quire  easy  access  to  help  information  describing  features  and  functionality 
of  KBSA  components  such  as  the  Requirement  Assistant,  the  Specifica¬ 
tion  Assistant,  editors,  and  compilers.  Users  also  require  easy  access  to 
data  in  the  knowledge  base  such  as  available  resources,  schedules,  and  task 
assignments. 

Finally,  since  users  have  diverse  backgrounds  and  varying  degrees  of 
technical  knowledge,  the  interface  should  have  some  mechanism  for  user 
modeling  19  .  This  includes  determining  and  recording  a  user’s  beliefs, 
goals,  plans,  and  knowledge  in  an  attempt  to  tailor  the  system’s  interaction 
with  the  user.  In  doing  so,  the  system  can  mrre  appropriately  determine 
what  kinds  of  information  to  supply  the  user,  it  can  more  actively  assist 
the  user  in  achieving  their  goals,  and  it  can  detec i  inappropriate  plans  for 
achieving  those  goals. 

2.2  User  Interface  Design  Principles 

Many  approaches  can  be  taken  to  satisfy  these  requirements  for  an  effective 
user  interface.  In  determining  which  approach  is  appropriate  in  each  situa¬ 
tion  one  should  attempt  to  follow  design  principles  such  as  those  described 
in  4.15  .  In  4  .  Gould  and  Lewis  suggest  four  guidelines: 

1.  Focus  on  users  early  to  determine  their  needs  and  capabilities. 

2.  Use  an  interactive  design  process  in  which  potential  users  are  part  of 
the  design  team. 

3.  Attempt  to  empirically  measure  the  usability  and  learnability  of  the 
interface. 


4.  Use  an  iterative  design  process  in  which  suggested  changes  or  en¬ 
hancements  are  incorporated  in  the  next  design. 

In  15  .  Rich  suggests  seven  factors  to  consider  in  determining  how  to 
provide  required  functionality: 

1.  Cost  of  the  interface.  Different  kinds  of  interfaces  (menu,  command- 
line.  graphical,  natural  language,  etc.)  require  differing  amounts  of 
effort  in  implementation  and  maintainence.  The  cost  must  be  bal¬ 
anced  against  the  required  functionality. 

2.  Ease  of  learning.  Some  interfaces  (menu,  natural  language)  are  easier 
to  learn  than  others.  The  interface  complexity  must  be  geared  toward 
the  user  community. 

3.  Conciseness.  Some  interfaces  (menu,  keyword)  are  more  concise  and 
require  less  interaction  to  communicate  something.  The  concise¬ 
ness/verbosity  of  the  interface  must  correlate  with  the  tasks  to  be 
performed. 

4.  Need  for  precision.  Some  interfaces  (natural  language)  are  less  precise 
than  others.  The  precision  of  the  interface  must  match  the  precision 
required  by  the  task. 

5.  Need  for  pictures.  In  many  cases,  pictures  communicate  information 
much  better  than  text.  The  interface  should  be  capable  of  displaying 
pictures  whenever  appropriate. 

6.  Semantic  complexity.  The  required  complexity  of  the  interface  is 
directly  proportional  to  the  complexity  of  the  task  being  performed. 
The  interface  must  balance  its  own  complexity  against  that  of  the 
tasks  it  will  be  used  to  perform. 

7.  Promising  more  than  can  be  delivered.  In  most  cases,  if  a  system  has 
a  complex  interface,  users  will  expect  complex  behaviour  from  the 
underlying  system.  The  interface  must  not  mislead  users  by  shrouding 
a  simple  system  in  a  complex  interface.  Interface  designers  must  be 
careful  to  balance  the  interface’s  complexity  against  the  complexity 
of  the  underlying  system. 

By  following  these  guidelines  and  keeping  in  mind  the  desirable  U/I  at¬ 
tributes.  an  effective,  helpful,  and  easy  to  use  U /I  can  be  constructed  for  the 
diverse  KBSA  user  community  which  meets  all  of  the  above  requirements 
and  provides  the  appropriate  mix  of  functionality  and  complexity, 


3  User  Interface  Architecture 


This  section  describes  the  U  I  functional  requirements  of  tin  KB 5 A  sys¬ 
tem  and  discusses  possible  approaches  in  each  area  Currently  we  have 
identified  five  areas  in  which  U/I  plays  a  role.  Tieese  areas  are:  a  runtime 
support  environment,  a  PMA  interface,  a  Help  'Tutor  facet,  a  Query  facet, 
and  an  Inspector  facet.  Each  of  these  areas  is  considered  it)  turn,  along 
with  possible  approaches  to  providing  the  capabilities  described. 

3.1  Runtime  Support  Environment 

The  runtime  support  environment  provides  a  set  of  routines  available  for 
use  in  constructing  user  interfaces  for  the  various  facets.  It  should  in¬ 
clude  routines  for  window  management,  icon  definition,  user  input,  menu 
definition,  mouse  sensitivity,  program  output,  etc.  Input  routines  should 
support  both  command-line  (textual)  and  mouse-driven  input.  Output 
routines  should  support  both  textual  and  graphical  display  of  information. 
Since  standards  are  beginning  to  emerge  in  this  area,  one  of  the  proposed 
window  management  standards,  such  as  |7;,  would  he  adequate  to  support 
these  capabilities. 

The  runtime  support  environment  should  also  specify  a  set  of  candidate 
interface  standards /Conventions  which  facets  should  follow  in  their  interac¬ 
tions  with  users.  As  mentioned  earlier,  no  such  standards  exist.  However, 
the  KBSA  should  specify  some  conventions  for  user  to  facet  interaction 
based  on  the  desirable  U/I  attributes  described  earlier.  This  will  provide 
for  increased  consistency  across  facet  boundaries,  and  will  not  force  users 
to  learn  different  interface  conventions  for  different  facets.  Of  course,  these 
standards  should  evolve  as  more  is  understood  about  U/I  in  general  and 
KBSA  U  I  in  particular. 

3.2  PMA  Interface 

The  PMA  Interface  provides  the  link  between  users  and  the  PMA.  This  in¬ 
teraction  will  occur  primarily  whenever  project  policy  cannot  autonomously 
determine  which  action  to  perform  next.  For  example,  suppose  a  developer 
finishes  the  first  of  three  assigned  tasks.  Further,  at  that  point,  policy 
dictates  that  they  begin  working  on  any  remaining  tasks  they  are  respon¬ 
sible  for.*  However,  since  two  tasks  remain,  the  system  cannot  determine 
which  task  the  developer  should  begin  next.  The  developer  must  decide 
and  inform  the  system  which  task  to  select.  As  another  example,  suppose 
a  developer  successfully  finishes  testing  a  specification.  At  that  point,  pol¬ 
icy  allows  the  developer  to  go  back  and  modify  the  requirements  associated 


with  the  specification,  or  to  submit  the  specification  and  the  test  results 


m 


>?v;vV v* •av.v.v 


jgsgsg 


c  j-.  j._v» 


for  review.  Again,  the  system  ca..no  tote* mme  w;.(  ;  -  p  jn  tr.  take  next 
based  on  this  policy.  The  develop  s  must  v-c.-.w . 

In  such  situations,  the  system  would  invoke  tne  ?MA  interface.  First, 
this  interfe.ce  would  prioritize  the  aitc-nariv  actio  .s  based  on  PMA  in¬ 
formation  such  as  scheduling,  resource  ava;Uh'i:Ty  anr  ka.nvn  priorities. 
Then,  it  would  present  the  user  with  *  he  prioritized  alternatives.  To  pro¬ 
vide  this  b  nctionaiity,  a  siinpi-r  mens  .von id  be  adequate.  Higne:  priority 
options  could  appear  at  the  tot  o  t he  menu  while  iov «r  priority  options 
would  appear  at  the  bottom  or.  cl:.:  alternativt  could  be  explicit iy  prior¬ 
itized. 

This  will  provide  the  basic  functionality  required  of  the  PMA  Interface. 
However,  in  the  long  run.  some  sort  oi  explain  Aon  mechanism  wiii  probably 
be  required.  Users  will  want  to  know  why  the  PMA  recommends  that  they 
proceed  with  some  task  while  postponing  others:  or.  they  m--.y  warn  to 
validate  its  reasoning  in  weighting  their  tasks  if  those  tasks  are  critical 
to  a  project.  Several  such  systems  exist  ‘18.2.5.  It  is  uncertain  whether 
trds  functionality  should  reside  in  the  PMA  or  in  the  PMA  Interface,  but 
in  either  case,  the  appropriate  subsystem  could  incorporate  an  explanation 
mechanism  based  on  some  form  of  simple  command  language  (o*  a  short  lis t 
of  mouse  selectable  commands)  for  requesting  various  types  of  explanation 
(e:g.  EXPLAIN.  VERIFY,  etc.).  Responses  could  be  based  on  simple, 
built-in  answers  to  this  limited  set  of  questions  However,  this  form  of 
interaction  would  probably  prove  too  restrictive.  In  order  to  provide  a 
truly  effective,  broad-range  of  interaction,  a  more  flexible  and  powerful  form 
of  communication  would  be  necessary.  Thus,  the  explanation  mechanism 
could  be  based  on  Natural  Language  (NL).  In  such  a  system,  users  could 
request  explanations  and  verifications  of  the  PMA  >.  reasoning  in  NL  and 
they  would  receive  responses  in  NL  generated  for  the  specific  situation. 


3.3  Help/Tutor  Facet 

The  Help 'Tutor  facet  provides  ar.  intelligent  help  facility  to  the  users  of 
KBSA.  It  will  provide  explanations  of  how  to  use  individual  facets  and  the 
KBSA  as  a  whole.  To  provide  this  functionality,  as  new  facets  or  tools  are 
integrated  into  the  KBSA.  knowledge  about  their  features  and  us.j  also  must 
be  integrated.  The  Help  'Tutor  facet  will  use  this  information  ro  describe 
components  tc  the  user  For.  example,  suppose  a  developer  is  working 
on  a  K3SA  system  on  which  a  new  editor  has  been  ins  railed  along  wbh 
knowledge  of  its  features  and  functionality.  Now,  if  the  developer  wishs  to 
learn  how  to  use  the  new  editor,  they  merely  invoke  the  Help/ dutor  fo-et 
and  request  an  explanation  of  the  editor.  At  that  point,  they  may  ass  for 
information  such  as  how  tc  save  a  file,  how  to  delete  a  line,  o:  how  o  move 
a  block  of  text. 


io*. 


There  are  at  least  four  options  for  providing  tv  s  f  net:  r  ..  y  '■  ?v- 
word.  menu-driven, document  browser,  and  NL.  FI.*.-’;, c  .•  «  .  >vd 
approach,  users  enter  a  special  command,  ?uch  a «  "TIL..  r'.  toll.-  :d  Iv 
keywords,  such  as  a  command  name,  options,  or  p-. .1  l;  The 
mam  advantage  of  this  approach  is  its  simp!ic:t\  it  .r:.-  .  nor..  The 

main  disadvantages  are  that  it  can  be  too  restrictive,  r  ii-rve*  users  to 
kr.o.v  which  terms  are  allowed  in  constructing  a  roq.  .  arr  many  icpiies 
are  typically  cryptic  and  uninformative.  A  similar,  though  less  restrictive 
technique  is  described  in  [16..  which  uses  an  ELIZA-hasf  ^  parser  to  ex¬ 
tract  keywords  from  NL  inputs.  These  keywords  a* e  then  used  to  match 
substitution  patterns  from  which  an  NL  response  i~  constructed. 

Second,  in  a  menu-driven  approach,  the  system  display'  menus  offer¬ 
ing  additional  information  [3’j.  As  with  the  keyword  appr  vc.h,  the  main 
advantage  of  this  approach  is  its  simplicity  of  imp iernerr  !.ts  main 

disadvantages  are  that  it  is  even  more  restrictive  arc  iuhexmie  than  the 
keyword  approach,  and  again,  many  replies  me  typically  tryptic  and  unin¬ 
formative. 

Third,  in  a  document  browser  approach,  users  c.ai;  browse  through  on¬ 
line  documents  by  referring  to  chapters,  sections,  subsections,  c-  paragraphs 
13’.  Again,  the  main  advantage  of  this  approach  is  its  simplicity  of  im¬ 
plementation.  The  main  disadvantages  are  that  the  -ep'ies  are  only  as 
good  as  the  underlying  documentation,  and  again,  softwo.ee  documentation 
is  notorious  for  being  cryptic  and  uninformative  Further,  depending  on 
the  underlying  structure  of  the  document,  the  am, mu:  of  time  required  to 
find  the  desired  information  may  be  large.  However,  if  the  documentation 
is  broken  up  into  many  small  pieces  and  stored  ?.s  a  mghly  interrelated 
network  12.,  users  can  quickly  cross-reference  inform -‘ion,  the  system  can 
avoid  duplication  overheads,  and  related  informat i •  can  be  inferred  from 
well-defined  network  relationships. 

Finally,  in  a  NL  approach,  users  car  request  and  receive  help  in  NL 
20  .  The  main  advantages  of  this  approach  are  that  users  need  not  learn 
a  command  language.  NL  is  very  flexible  and  powerful,  responses  can  be 
tailored  to  individual  users,  and  the  implementors  have  greater  leeway  in 
providing  additional  features  to  help  users  clarify  confusing  responses.  The 
main  disadvantages  are  that  effective  NL  interfaces  are  generally  more  ex¬ 
pensive  and  much  more  complex  than  other  interfaces,  and  NL  queries  tend 
to  be  more  verbose  than  other  types  of  queries. 

3.4  Query  Facet 

The  Query  facet  provides  users  with  a  facility  for  accessing  the  knowledge 
base.  It  will  allow  them  to  formulate  queries  (requests  for  information), 
translate  these  queries  into  a  query  format  recognizable  to  the  underlying 
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to  other  objects  (essentially  a  special  kind  of  sic  t  mi  va.v  :  •’  >:;»  this 

information,  they  then  can  traverse  the  relationships  euc  mv,-*-;  • — ,»ex 
objects,  thereby  walking  through  the  knowledge  Ir  a'5  r  i  sc:- 

will  be  able  to  modify  a  displayed  object's  stale.  They  -<  rcess  to 

methods  which  allow  them  to  assign  values  to  .*  cMe  .t  s  *.  They  "--ill 
also  have  access  to  tne  methods  which  arc  define  or  tne  oty  c*  fj.e..  they 
are  part  of  the  object's  class  definition!.  The  Ins  pee  m;  ?  •••  :lj  prov » la 
a  valuable  debugging  tool  for  both  KBS  A  users  and  ■r"r  '-\ZtzK  system 
developers. 


4  Summary  and  Conclusions 

•» 

Given  the  above  five  areas  of  U/I  support,  KbSA  us--v"  w-A  have  an  ef¬ 
fective  interface  to  the  KBSA.  They  will  have  access  tc  P V..-  nation 
and  on-line  Heip  facilities,  and  they  will  have  a  knov’eoge  Pace  query  ca¬ 
pability.  KBSA  system  developers  vTli  benefit  from  ::u  rur’ime  support 
environment  and  the  Inspector  facet  The  runtime  support  environment 
will  provide  a  common  poo!  of  screen, vimo..  mar.:- gem 'in'  ;  uitines,  and 
the  accompanying  standards /conventions  which  will  provic. .  r-  fairly  stable 
basis  for  interface  development. 

However,  even  with  this  kind  of  support,  users  may  still  reject  KBSA. 
U  I  designers  must  be  careful  to  concentrate  on  providing  an  interface 
which  possesses  the  desirable  attributes  of  consistency,  inruitiveness,friend- 
lvness.  helpfulness,  and  user  modeling.  They  must  also  be  careful  to  follow 
good  design  principles,  such  as  thorn  described  earlier.  Finally,  U/I  design¬ 
ers  must  remain  open  to  new  ide?.s,  so  that  as  research  provides  further 
insight  into  what  constitutes  a  good  U/l,  tl.;y  wvl  be  willing  to  try  those 
ideas  and  incorporate  the  best  of  them 
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OVERVIEW 


The  focus  of  the  Knowledge-Based  Software  Assistant  <~j  if  orences 
is  on  advanced  automated  software  development  too  c,  and  this 
year's  theme  is  Technology  Transfer.  While  adder  log  to  these  con¬ 
cerns,  this  presentation  departs  from  the  more  "ypicai  tool  as¬ 
sumptions  in  that  it  is  concerned  with  he  development  of 
knowledge-based  tools  and  procedures  primarily  for  kr owledga-based 
software  systems. 

Our  concern  for  such  tools  derives  from  the  emergence  of  a  new 
business  area  in  which  customers'  significantly  large  problems 
appear  not  to  be  satisfiable  by  traditional  software  and  prac¬ 
tices.  These  problems,  while  involving  traditional  system  inte¬ 
gration  and  communication  issues,  have  at  chair  core  a  large 
expert-system  component  requiring  AI  methodology  and  technology, 
at  least  for  the  development  --  if  not  the  delivery  --  system.  A 
critical  requirement  common  to  most  of  these  problems  is  that  the 
expert-system  piece  can  seldom  stand  alone  as  a  kind  of  consultant 
environment  outside  of  and  in  remote  comnunicacicn  with  the 
customer's  system.  Rather,  the  AI  software  must  be  embedded  within 
the  total  software  environment,  to  be  compiled,  called,  used,  and 
banished  just  like  any  other  specialized  software  package  or 
utility.  This  requirement  is  not  only  a  technical  one  --  how  to 
implement  an  embedable  expert-system  --  but  it  is  also  an  admin¬ 
istrative  one  in  that  the  AI  component  must  be  manageable  like 
other  software  susbsystems  with  reviews,  tests,  configuration 
management ,  etc.;  and  for  government  customers  this  means  putting 
the  AI  piece  under  the  aegis  of  formal  --  and  formidable  --  mili¬ 
tary  standards  (e.g.,  MILSTDs  490,  483,  and  2167).  Reasonable  as 
this  may  be,  the  major  difficulty  of  complying  is  that  there  is 
so  little  experience  with  AI  systems,  particularly  large  ones, 
that  there  is  barely  the  notion  of  a  system  life-cycle  much  less 
a  consensus;  without  a  well-specified  life-cycle  there  is  little 
basis  for  scheduling  reviews,  for  costing,  for  documentation,  or 
generally  for  any  of  the  typical  management  activities  which  in¬ 
sure  the  successful  completion  of  large  software  projects. 

This  presentation  overviews  three  aspects  of  our  approach  to 
remedying  this  situation:  (a)  a  proposed  life-cycle  for 
Knowledge-Eased  Systems  (KBSs);  (b)  techniques  for  knowledge-base 
verification,  and  (c)  representation  and  traceability  of  Require¬ 
ments  . 


A  PROPOSED  KBS  LIFE-CYCLE 


If  one  wanted  to  emphasize  the  differences  between  KBS  and  tradi¬ 
tional  systems,  one  might  choose  to  represent  their  respective 
life-cycles  as  shown  in  Figure  1.  Not  only  are  the  stages  dis¬ 
similar  but  so  also  are  the  operations  that  are  performed  to  move 
from  stage  to  another.  Without  discussing  this  contrast  fully  we 
note  that  each  life-cycle  does  a  different  thing  best:  for  the 
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traditional  waterfall  method  it  is  the  traceability  cf  requirements, 
but  for  the  KBS  method  it  is  the  visability  of  the  Operational  Concept 
that  is  most  striking. 

We  believe  that  Figure  1  is  a  useful  and  defensible  view  of  the 
contrasts  among  many  present-day  KBS  and  traditional  life-cycles, 
especially  during  development.  However,  fcr  the  longer  view, 
which  takes  in  transitioning  from  development  system  to  delivery 
system,  through  integration,  out  into  the  far  reaches  of  mainte¬ 
nance,  we  propose  a  different  pair  cf  life  cycles,  as  shown  in 
Figure  2.  These  emphasize  the  essential  similarities  in  the 
building,  fielding,  and  maintain.’  v.y  of  all  large  complex  systems 
--  whether  they  are  KBS  in  an  AI  language  or  traditional  systems 
with  procedural  code.  L->.i e  the  successive  stages  are  the  same  in 
both  cases;  it  is  presumed  that  the  requirements  are  not  perfectly 
understood  for  both,  hence  the  need  for  a  development  system  to 
support  prototyping  prior  tc  a  probably-rewritten  delivery  system. 
Test  and  integration  is  placed  after  the  delivery  system  phase  to 
emphasize  that  the  system  being  developed  by  these  life-cycles  is 
part  of  some  larger  complex  system.  The  key  distinction  is  that 
for  KBSs,  the  Knowledge  Acquisition  phase  --  comparable  in  some 
respects  to  Traditional's  Requirement  Specification  phase  --  is 
replicated  n  a  limited  extent  for  all  phases  of  the  KBS  cycle, 
as  shown  by  the  vertical  column  connecting  to  each. 

We  call  this  view  the  Elevacor  Model  to  emphasize  the  top-level  im¬ 
portance  of  Knowledge  Acquisition  for  KBS  products  whereby  diffi¬ 
culties  in  all  succeeding  phases  can  De  addressed  by  initially 
spending  considerable  time  in  knowledge  acquisition  anticipating 
problems  in  subsequent  phases  and  then  responding  to  the  remaining 
inevitable  problems  in  successive  phases  by  essentially  bringing 
them  up  to  the  Knowledge  Acquisition  phase  and  reworking  the 
knowledge.  This  view  was  developed  primarily  in  the  interests  of 
assuring  the  verifiability  of  knowledge-bases,  and  maximizing 
their  validity,  particularly  for  systems  not  easily  accessible 
after  deployment,  and  it  was  presented  at  length  in  a  recent  NASA 
conference  (Miller,  1937). 

The  means  by  which  the  Elevator  Model  achieves  its  goals  is  to 
elaborate  the  initial  acquisition  phase  into  three  pairs  of 
knowledge-development  activities,  as  shown  in  Figure  3;  each  first 
element  of  the  pair  is  tightly  coupled  to  an  intensive  testing 
partner,  and  the  three  pairs  are  somewhat  more  iooseiy  coupled  tc 
each  other.  The  first  of  these  stages  is  Knowledge  Acquisition, 
per  se,  and  we  are  exploring  a  variety  of  techniques  to  facilitate 
and  even  automate  this  process.  The  second  stage  is  to  amass, 
coordinate,  and  transform  relatively  "raw"  acquired  knowledge  into 
a  common  formal  representation  system  suitable  for  verification 
testing;  details  of  this  stage  will  be  covered  in  the  next  two 
sections  of  this  present  overview.  The  third  stage  is  to  map  the 
formal  knowledge  into  whatever  rule  syntax  is  used  by  the 
expert-system  shell  for  prototyping;  in  the  case  of  IBM's  ESE 
(Expert  System  Environment)  product,  this  means  converting  the 
declarative  knowledge  base  into  ESE  Parameters,  ESE  Rules,  and 
execution-controlling  structures  called  Focus  Control  Brocks  (IBM 
FSD's  internal  HiPEP  system  --  for  High  Performance  Embedded 


Reasoning  --  is  our  current  approach  to  an  ir.ievf  .re  engine  for 
embedded  KBS  and  would  involve  the  generation  of  sciif. what  differ¬ 
ent  rule  syntax;  cf.  Arbabi  &  Highland,  1986,  pp .  2J-U 

While  the  few  discussions  of  KBS  life-cvcles  that  are  published 
certainly  do  open  up  a  host  of  new  opportj r.i  t  i es  for  "smart" 
tools,  this  present  life-cycle  offers  ever  more  openings  with  its 
elaboration  of  the  initial  acquisition  phase  mtc  one  3  paired 
cycles,  prior  to  any  prototype  development. 


KNOWLEDGE  BASE  VERIFICATION 


The  second  phase  of  the  expanded  Knowledge  Acquisition-  stage, 
shewn  in  Figure  3,  involves  the  semantic  interpretation  and  coding 
of  obtained  knowledge  into  a  formal  system  which  is  governed  by  a 
new  evolving  approach  we  call  KNOWLEDGE  REPRESENTATION  THEORY  ( KRT )  . 
Not  only  does  KRT  provide  opportunities  for  formal  verification, 
as  summarized  here,  but  also  it  appears  more  and  more  likely  that 
it  can  guide  the  development  of  structured  interviewing  techniques 
and  the  automation  of  subsequent  knowledge  transformation  into  KRT 
f ormali sms . 

The  basic  KRT  strategy  is  fourfold:  (1)  to  develop  a  system  of 
knowledge-elements  which  is  rich  and  comprehensive  enough  to  cap¬ 
ture  the  complexities  of  modern-day  systems  and  their  development; 
(2)  tc  develop  a  syntax  and  set  of  formalisms  for  expressing  all 
of  the  semantics  of  a  concept  in  an  explicit,  declarative  manner, 
without  recourse  to  deus-ex-machina  tricks  such  as  DEMONS  or 
arbitrarily-inserted  LISP  (or  other)  code;  (3)  to  generate  a  base 
of  several  hundred  concepts  for  serving  as  a  "core"  for  new 
customer- system  knowledge  (and  for  developing  editing  and  other 
aids  to  facilitate  elaboration  of  concepts);  and  (4)  to  perfect  a 
set  of  procedures  for  automating  formal  verification  of  each  new 
element  of  the  knowledge-base. 

Figure  4  illustrates  a  simplified  view  of  KR'J's  basic  knowledge 
elements:  frames  containing  three  types  of  slots  ("c_"  slots  -- 
required  header  information;  definitional  slots,  with  no  prefix; 
and  "typ"  slots  --  slots  indicating  typical,  but  not  necessary, 
information;  only  the  first  two  are  shown)  .  One  of  the  key  ar¬ 
chitectural  decisions  of  KRT  was  to  require  every  slot  and  every 
slot-value  to  have  its  own  separate  definition  frame.  This  pro¬ 
vides  the  basis  for  a  SEMANTIC-NETWORK-like  richness  of  association 
among  concepts  in  addition  to  the  usual  hierarchical  inheritance 
and  coupling  structure  provided  by  the  generalization  ("genzn") 
and  specialization  ("speczn")  slots:  one  frame  is  linked  to  oth¬ 
ers  not  only  by  its  "ISA"  links  (to  use  common,  but  objectionable, 
terminology),  but.  also  by  every  definitional  or  typical  slot  that 
occurs  on  it,  and  further  by  every  value  and  every  operator  ac¬ 
companying  these  slots  (as  shown  by  the  arrows  from  the  central 
"ADULT"  frame  to  the  other  frames  in  Figure  4). 


The  very  same  architectural  requirement  which  supports  such  asso¬ 
ciative  richness  also  provides  the  basis  tor  automated  verifica¬ 
tion,  in  that  a  large  number  of  syntax  requirements  have  to  be 
observed  before  all  the  elements  on  a  single  frame  --  a  single 
"knowledge  element"  --  can  be  said  to  be  correct.  Some  of  these 
requirements  are  listed  in  Figure  5,  which  also  makes  the  point 
that,  when  all  requirements  are  met  for  a.  single  frame,  then  that 
frame  can  be  termed  a  WELL-FORMED  KNOWLEDGE  ELEMENT,  or  WFKEL  -- 
harking  back  to  the  concept  of  Weil-Formed  (logic)  Formulas  -- 
WFFs  --  some  decades  ago. 

Re-examination  of  Figure  4  indicates  at  least  two  problems  for  the 
ADULT  concept- frame  according  to  these  well-formedness  criteria: 
neither  the  operator  GT  nor  the  entity  legal_adult  have  a  separate 
defining  frame.  Were  these  two  frames  defined,  and  were  the  other 
syntax  to  be  correct,  then  it  would  be  the  case  that  the  ADULT 
frame  would  be  a  WFKEL,  a  verified  trusted  item  of  knowledge  which 
will  retain  its  lofty  status  no  matter  how  used,  as  long  as  it  and 
the  frames  on  which  it  depends  are  not  changed. 

Verifiability,  then,  can  be  achieved  by  automated  syntax-checking 
means  given  KRT  and  the  frame  formalisms  (our  specifications  stay 
within  the  .iorn-clause  subset  of  first-order  predicate  calculus, 
and  w a  do,  in  fact  but  not  of  necessity,  use  PROLOG  to  accomplish 
syntax-checking).  While  verifiability  guarantees  only  syntactic 
correctness  and  overall  reliability,  still  it  greatly  promotes 
validity  and  completeness,  since  the  simple  requirement  of  defining 
everything  will  force  the  elicitation  of  more  and  more  information 
from  the  knowledge  suppliers  and  will  provide  the  best  possible 
environment  for  them  to  discover  for  themselves  that  they  forgot 
or  mis-stated  something. 


REQUIREMENTS  TRACEABILITY 


This  issue,  in  the  large,  deals  with  whether  what  you  finally  got 
is  what  you  said  you  wanted  in  the  first  place;  in  the  small  it 
deals  w’ith  seeing  that  this  phase  of  development  preserves  the 
same  system  goals  achieved  in  the  previous  phase.  The  process 
begins  with  the  customer's  expression  of  an  "Operational  Need", 
translated  into  a  set  of  "requirements"  which  lead  to  an 
agreed-upon  set  of  "specifications",  often  called  the  "A-Spec". 
This  process  may  not  be  as  much  a  traceability  problem  as  it  is  a 
knowledge  problem:  often,  particularly  for  problems  involving  the 
computerization  of  what  people  used  to  do,  ;ou  don't  really  know 
exactly  what  it  is  you  think  you  need. 

It  is  the  articulation  of  the  A-Spec  into  a  set  of  B-Spec  design 
components,  often  called  CPCIs  (Computer  Program  Configuration 
Item)  which  is  the  biggest  traceability  difficulty.  The  CPCIs, 
the  so-called  B5s,  are  the  result  of  taking  che  requirements  as 
expressed  in  the  A-Spec  and  --  via  a  series  of  complex  architec¬ 
tural  activities,  trade-off  studies,  system  engineering  parti¬ 
tioning  of  hardware  and  software,  and  innumerable  design 
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considerations  --  producing  a  set  of  procedural  j.  restr  iptions  for 
accomplishing  the  previously  declarative  goals.  The  final  steps 
are  those  of  detailing  each  B5  into  a  much  more  explicit  C5  design 
and  then  into  its  C5  implementation. 

While  the  development  of  B5s  from  the  A-Spec  is  surely  che  meat 
challenging  traceability  problem,  ail  steps  ar?  ;  oMematic  be¬ 
cause  new  information  is  introduced  in  each,  pr:mari;.y  due  to  the 
increase  in  specificity  (of  candidate  concepts),  j:.  interactivity 
of  components,  in  quantification,  and  in  the  detail  of  resource 
consideration.  Despite  many  years  and  many  cornicing  approaches, 
there  is  still  no  technique  or  product  which  can  effectively  as¬ 
sure  that  requirements  from  one  stage  co  another  not  only  can  be 
traced  but  can  be  assessed  as  having  been  met. 

While  it  is  much  too  early  to  claim  success  for  our  KRT  approach, 
we  do  believe  it  shows  great  promise  for  meeting  these 
traceability  goals.  Whereas  a  major  difficulty  with  traditional 
life-cycle  traceability  has  been  the  fact  that  it  is  terribly 
difficult  to  compare  the  results  of  one  stage  with  another  --  they 
are  so  very  different  in  structure  and  content  --  the  great 
strength  of  our  technique  is  that  the  results  of  each  stage  will 
look  extraordinarily  similar.  This  is  because,  given  Knowledge 
Representation  Theory,  they  all  are  represented  by  the  same  frame 
formalisms  and  have  considerable  overlap  in  slot  types  and  easily 
traceable  elaboration  of  slot  values. 

Consider,  for  example,  the  invention  of  the  wooden  erase  perncil 
in  the  early  20th  centruy,  say  by  the  Acme  Company.  The  initial 
Operational  Need  might  have  been  simply  to  develop  a  cheap, 
easy-to-use,  writing  instrument  whose  marks  were  not  to  be  perma¬ 
nent  but  somehow  reversible.  This  situation  is  represented  in  the 
top  panel  of  figure  6.  Only  a  Tew  of  the  needed  slots  are  shown, 
but  the  key  one  is  char_values.  standing  for  ''characteristic  val¬ 
ues",  one  of  several  means  for  formally  representing  ill-defined 
general  performance  criteria  (the  slot  c_inten;  normally  has  the 
value  "real",  indicating  that  the  concept  describes  real  in¬ 
stances;  c_link  associates  this  ad  hoc  operational  need  for  a  pen¬ 
cil  to  the  general  well-developed  base-concept  of 
" operational_need" ;  c_next  implies  a  frame  sequence  and  specifies 
the  next  one  in  succession) . 

In  the  middle  panel  of  Figure  6  the  initial  vague  performance  ob¬ 
jectives  have  been  sharpened  up:  the  marks  should  not  be  perma¬ 
nent,  the  instrument  should  cost  less  than  10  cents,  and 
"easy-to-use"  now  means  "easy-to-hold"  ans  well  as 
"easy-to-operate . "  In  the  bottom  panel  there  is,  for  the  first 
time,  an  expression  of  how  the  inst  rument  is  to  be  constructed 
--  in  the  design  frame  --  in  which  the  concept  of  "operation"  is 
designed  at  this  high  level  to  be  two  modes,  one  for  writing  and 
one  for  erasing,  with  the  "ease"  criterion  being  asserted  for  the 
latter.  The  next  frames  might  be  detailed  designs  or  the  first 
implementations,  in  which  case  the  name  slot  would  not  be  c_name 
but  i  name,  which  stands  for  "instance_name" . 


21: 


•*  ,  ■*«  ‘  1  »  v  '/ 


“iVi 


We  believe  that  the  two  key  processes  of  (1)  tracing  requirements 
and  (2)  assuring  that  they  are  met  in  each  next  phase  is  an 
automatable  process  if  the  specification  procedures  outlined  in 
Figure  6  are  followed  and  if  each  specification  frame  is  assured 
to  be  a  WFKEL,  just  like  the  basic  concepts.  This  procedure  can 
be  used  even  if  the  implementation  of  a  design  was  not  formally 
generated  from  C5  descriptions,  but  rather  from  iterative  rapid 
prototying,  for  example.  All  this  is  required  is  that  the  imple¬ 
mentation  be  documented  according  to  the  KRT  formalisms  to  produce 
frames,  and  these  can  then  be  compared  to  the  Requirements  and 
Design  specif ications . 


SUMMARY 


What  has  been  presented  here  is  admittedly  an  early  program  of 
research  on  KBS  tools  for  working  to  retain  all  which  is  good  about 
managing  traditional  software.  The  key  thrust  of  the  proposed 
techniques  is  to  move  as  much  as  possible  of  the  development  of  a 
KBS  system  to  the  initial  life-cycle  stage  of  Knowledge 
Acquistion,  and  then  to  accomplish  very  extensive  verification  by 
formal  automated  means.  What  is  tantalizing  about  this  kind  of 
KBS  emphasis  is  the  possibility  that  some  of  those  lofty  ideals 
of  traditional  software  development  —  such  as  making  changes  in 
an  operational  system  by  changing  the  design  and  propagating  that 
forward  --  may  actually  have  a  greater  chance  of  being  satisfied 
for  the  new  AI/KBS  systems  than  for  the  traditional  programming 
language  ones. 
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Knowledge  Well-Formedness  (WF)  Criteria 


Does  each  Concept  Element  (Intention  or  Extension)  have  a 
Definition  Frame? 

If  an  extension,  is  correct  extenslonal  syntax  observed? 

Are  Obligatory  Slots  present  with  correct  syntax  and  values? 

Is  there  at  least  one  definitional  -  slot? 

Does  eacn  slot  have  Its  own  definition  frame? 

Are  the  conventions  of  slot-value  expression  observed? 

Are  the  conventions  of  SVARIABLE  usage  observed? 

Does  every  value,  operator,  ana  argument  have  It  own 
definitional  frame? 

THEN  YOU  HAVE  A 


(Well-Formed  Knowledge  ELement) 


(A)  OPERATIONAL  NEED 


c_name($0,  writer . oper_need) 
c_intent($0,  goal(ACME)) 
c_link($0,  operational_need) 
c_next($0,  writer. reqs) 


primary_use( $0,  to_write(nil ) ) 

char_values( $0,  cheap,  not_permanent,  easy_to_use  ) 


(B)  REQUIREMENTS 


c_name( $0, 
c_prev( $0, 
c_next( $0, 


writer . reqs ) 
writer. oper_need) 
writer . design) 


primary_use( $0,  to_write( ( $A1  =  role(actor,  person)), 
role (instrument,  SINSTR),  role(medium,  paper), 
consequences ( $P  =  on(marks,  paper)))) 
permanence ($P,  not (permanent) ) 

upper_bound(retail_cost($INSTR,  $VAL,  cents),  LT( $VAL,  10),  cents)) 
difficulty(to_hold($Al,  ($A2  *  role(object,  $INSTR)),  low) 
difficulty(to_operate($Al,  $a2),  low) 


c_name($0, 

c3>rev($°/ 

c_next( $0, 


writer .design) 
writer. reqs) 
writer. instance) 


(C) 


DESIGN 


operation8_modes( $0,  to_write,  to_erase  ) 


difficulty( to_erase($Al, $A2 ) ,  low) 


Figure  6 
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The  Knowledge  Integration  Tool: 
Knowledge  Interface  1 

ABSTRACT 


The  Knowledge  Integration  Tool  (KIT)  is  a  Knowledge  Based 
Environment  for  developing  and  using  Knowledge  Based  Systems. 

This  paper  contains  excerpts  from  a  thesis  which  studies  the  properties  of 
both  these  system  types  and  attempts  their  synthesis  in  the  KIT,  an  advanced 
prototype  of  a  Knowledge  Based  System  Development  Environment 
(KBSDE). 

The  KIT  facilitates  rapid  construction  of  programming  environments  and 
end-user  application  software.  Using  the  KIT,  conceptual  models  can  be 
created  composed  of  conceptual  primitives  for  agents,  activities,  causality, 
goals,  methodologies,  objects,  resources,  stales,  and  time.  A  Knowledge 
Based  Environment  and  the  Knowledge  Based  Systems  from  which  it  is 
composed  employ  the  conceptual  model  to  engage  in  autonomous  intelligent 
action  to  assist  the  user  in  his  activities.  The  KIT  employs  user  profiles  to 
construct  highly  specialised  environments  tailored  to  focus  the  user's  atten¬ 
tion  upon  just  the  knowledge  and  operations  pertinent  to  his  activities. 

The  KIT  possesses  the  rudiments  of  an  architectual  infrastructure  which  sup¬ 
ports  development  and  utilization  of  Knowledge  Base  Systems  and 
Knowledge  Based  Environments  within  the  Knowledge  Based  Corporation. 


Key  Words:  Artificial  Intelligence,  Distributed  Knowledge  Base, 
Knowledge  Based  Corporation,  Knowledge  Baaed  Design,  Knowledge  Based 
Environment,  Knowledge  Based  Interface,  Knowledge  Based  Project 
Management,  Knowledge  Based  Programming,  Knowledge  Based  Software 
Engineering.  Knowledge  Based  System  Development  Environment, 
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l.  Introduction 


The  advent  of  high-end  LISP  machines  and  the  availability  of  oojea  oriented  programming 
Languages  have  made  possible  the  class  of  knowledge  based  integrated  too!  ervu  exigents.  Such 
environments  are  characterized  by  the  ease  with  which  objects,  the  relationshij.-s  between  them,  and 
higher  level  concepts  composed  of  such  objects  and  relationships  can  be  represented  graphically.  Some 
such  systems  provide  multiple  views  of  knowledge  presented  based  upon  a  model  of  the  user  and  his 
application.  Depending  upon  the  sophistication  of  the  user  interface,  the  user  may  be  able  to  control  or 
change  the  way  the  system  provides  views  of  the  knowledge  base.  Such  systems  usually  provide 
automatic  graphical  draw  facilities  with  capabliles  usually  dependent  upon  the  complexity  of  the  graphs 
and  the  capabilities  of  the  ’layout  engine’.  The  user  interface  generally  provide  won  specific  pop-up 
menus,  interactive  viewports,  multiple  display  ports,  and  interaction  with  the  use-  by  means  of  high- 
resolution  bit  mapped  displays,  pointing  devices,  and  key  board  inputs.  3  3 

This  paper  provides  an  overview  of  the  properties  of  the  Knowledge  Integration  Tool,  a 
‘Knowledge  Based  Systems  Development  Environment'  which  serves  as  a  development  platform  and 
delivery  vehicle  for  Knowledge  Based  Systems  and  Knowledge  Based  Environments  fi.e.  computerized 
environments  constructed  to  manipulate  knowledge  bases  with  knowledge  based  systems).  The  func¬ 
tional  and  structural  features  of  the  Knowledge  Interface,  a  fast  and  flexible  interface  for  accessing 
knowledge  and  capabilities  in  die  KIT,  is  described  in  some  detail. 

While  the  KIT  may  be  used  for  program  development  and  program  construction,  it  can  be 
effectively  employed  to  gain  access  to,  to  reuse,  to  understand,  and  to  modify  already  existing 
knowledge  bases  and  knowledge  based  systems.  The  KIT  inherits  from  its  knowledge  based  foundation 
the  ability  to  be  rapidly  extended  to  new  problem  domains  in  hours  and  days  rather  than  in  the  months, 
or  even  years,  customarily  anticipated  for  conventional  systems. 

2  Smith,  R.G,  Dinitz,  R.,  Barth,  P.,  "Impulse-86:  A  Substrate  for  Object-  Oriented  Interface 
Design,"  ACM,  1986,  p.  167-175. 

3  Tichy  and  Ward,  ’A  Knowledge-Based  Graphical  Editor,"  submitted  to  ACM  Transaction 
on  Graphics,  special  issue  on  user  interfaces,  Carnegie  Group,  Inc.,  July,  1986. 


Properties  of  Knowledge  Based  Systems  Development  Environments 

To  help  provide  a  focus  for  the  discussions  of  the  Knowledge  Interface  which  follow,  the  capabil¬ 
ities  of  a  Knowledge  Based  System  Development  Environment  (KBSDE)  will  be  listed  below.  A 
KBSDE  should  support  many  of  the  following  features: 


1.  Incremental  knowledge  based  constructs  knowledge-of-ihe-small. 

2.  Knowlege  based  project  management:  knowledge-of-the-many. 

3.  Knowlege  based  management  and  control:  knowledge-of-the-large. 

4.  A  Knowledge  Based  approach:  knowledge  of  the  goals,  task  and  domain  of  the  pro¬ 
cess  to  which  it  is  applied.  This  knowledge  may  range  from  highly  specific  models  of 
the  problem  domain  to  which  it  is  applied  to  more  general  knowledge  about  bow  to 
generate  a  user  interface  based  upon  a  user  or  activity  model. 

5.  A  model  of  one  or  more  (software  engineering)  methodologies.  This  knowledge 
may  be  integrated  as  domain  knowledge  into  the  knowledge  base  to  be  used  within  a 
model  of  user  interaction. 

6.  An  integrated  rather  than  an  incremental  approach. 

7.  A  sophisticated  user  interface  with  icon  specific  commands,  pop-up  menus,  interac¬ 
tive  viewports,  multiple  display  ports,  and  interaction  with  the  user  by  means  of  high- 
resolution  bit  mapped  displays  and  automatically  drawn  displays. 

8.  Multiple  views  of  underlying  knowledge  based  upon  a  model  of  the  user  composed 
of,  but  not  limited  to,  objects,  relationships,  and  higher  level  concepts.  The  knowledge 
base  may  also  possess  knowledge  of  behavior  components  including  rules,  functions, 
demons,  methods,  productions,  etc....  Such  entities  can  be  presented  in  tables,  graphs, 
and  textually,  and  the  user  should  be  able  to  control  or  change  the  way  the  system 
provides  views  of  the  knowledge  base. 

9.  Facilities  for  rapid  construction  of  extensions  of  the  KBSDE  to  other  problem 
domains. 

The  problem  encompassed  by  these  requirements  is  so  very  broad  in  scope  that  even  if  a  single 
system  can  satisfy  them  there  is  a  risk  that  it  would  be  perceived  as  large,  unwieldy,  and  difficult  to  use 
and  understand.  Therefore,  substantial  effort  has  been  placed  into  developing  an  architectural  structure 
for  the  KIT  which  will  deliver  the  KIT's  capabilities  without  overwhelming  its  users. 


KIT  Components  Overview 

The  KIT's  major  components  are  described  below: 


o  The  Knowledge  Interface  is  the  KIT's  top  level  knowledge  interface  and  command 
shelL  It  is  much  like  an  encyclopedia  of  knowledge  which  provides  access  to  all 
accessible  knowledge  bases  and  knowledge  based  systems. 
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o  Knowledge-Qf-The-Small  is  concerned  with  helping  an  individual  programmer  or 
designer  develop  a  single  program  in  relative  isolation  from  other  programmers 

o  Knowledge-Of -The -Many  is  concerned  with  helping  groups  of  managers,  designers, 
programmers  and  users  manage,  develop  and  use  software  re  so  urn  es  m  coordination 
with  each  other. 

o  Kncwledge-Of-The -Large  is  concerned  with  controlling  the  eve'ujon  of  the 
knowledge  base  and  keeping  it  in  a  well  defined  state. 

o  Knowledge-Of-The-Moment  is  concerned  with  focusing  attention  upo~>  knowledge 
and  capabilities  which  are  pertinent  to  the  user’s  choice  of  activities,  roles  and  goals, 
t 

Krurwledge-Of -Itself  provides  the  user  with  a  cor  to  1  panel  which  pe-mits  the  user  to 
instantly  reconfigure  the  knowledge  based  environment  based  upon  his  profile  and  his 
needs. 

The  KIT’s  major  subcomponents  attempt  to  satisfy  the  following  requirements  of  a  KBSDE: 

1.  The  Knowledge  Interface  (human  and  knowledge  Interface)  supports  4,  5,  6,  7,  8. 

2.  Knowledge-Of-The-Small  (knowledge  based  system  design  and  construction)  sup¬ 
ports  requirements  1,  6,  7,  8,  9. 

3.  Knowledge-Of-The-Many  (project  management  and  knowledge  based  environment 
construction)  supports  requirements  2,  4,  6,  7,  8,  9 

4.  Knowledge -Of -The-Large  (distributed  knowledge  base  management  and 

configuration  control)  supports  requirements  3,  6,  7. 

At  this  writing,  the  KIT  is  maturing  as  a  delivery  vehicle  for  knowledge  based  technology  and  is 
already  a  dynamically  redefineable  environment  which  can  alter  itself  to  the  needs  of  its  users.  As  a 
member  of  the  class  of  knowledge  based  integral  :d  tool  environments,  the  KIT  Knowledge  Interface 
acts  as  a  flexible,  general  purpose  interface  for  a  wide  class  of  usts  to  many  kinds  of  applications  and 
knowledge.  The  KIT s  generality  comes  from  its  ability  to  use  a  profile  of  a  user  and  knowledge  con¬ 
text  and  command  context  specific  constraints  to  provide  access  to  just  the  tools  ar.d  knowledge  which 
a  user  needs  to  do  his  job.  The  KIT's  flexibility  comes  from  the  ease  with  which  the  KIT  can  be 
extended  to  incorporate  new  application  environments  as  they  are  developed,  even  if  they  were  not  ori¬ 
ginally  developed  with  or  as  pan  of  the  KIT. 


t  A  subset  of  this  capability:  Knowledge-of-its-History  appears  in  implementations  of  KIT  as 
of  June  1986 


2.  Capabilities 


The  Knowledge  Interface  serves  the  Knowledge  Integration  Tool  as  a  variable  width  communica¬ 
tion  channel  with  the  Knowledge  Based  Environment  (KTE)  and  acts  as  an  open  ended  framework  for 
architectural  extension.  The  rest  of  this  paper  reviews  the  way  the  Knowledge  Interface  can  be  used  to 
partition  the  knowledge  and  command  structures  of  the  knowledge  based  environment 

2.1.  Large  Grain  Knowledge  Partitions 

Knowledge  based  systems  of  any  sophistication  tend  to  become  large  and  complex.  A  knowledge 
based  environment  may  be  composed  cf  dozens  of  different  kinds  of  knowledge  based  systems.  The 
K3T  Knowledge  Interface  has  been  constructed  to  reduce  the  environment’s  complexity  while  at  the 
same  time  enhancing  the  user’s  ability  to  fully  understand  and  use  it  A  prominent  immediately  notice¬ 
able  feature  of  the  KIT  is  a  command  window  across  the  top  of  the  screen  where  there  are  icon  com- 
mands  for  switching  between  knowledge  partitions.  Selection  of  a  knowledge  partition  determines  the 
kind  of  knowledge  with  which  the  user  interacts.  A  user  can  change  knowledge  partitions  instantly  by 
simply  selecting  one  of  the  labeled  partitions.  Research  at  Carnegie  Mellon  University  on  the  Gandalf 
project  identified  three  kinds  of  knowledge  which  should  be  supported  by  any  software  development 
environment:  programming  in  the  many,  the  large  and  the  small.  4  The  KIT  emphasis  is  placed  upon 
knowledge  based  environments  rather  than  software  development  environments  (SDE).  Many  of  the 
same  kinds  of  issues  are  present  in  a  KBE  as  in  a  SDE  but  the  domains  are  quite  different.  While  a 
SDE  is  concerned  with  managing  resources  relative  to  programming  projects,  a  KBE  is  concerned  with 
managing  all  knowledge  based  resources  which  includes  all  knowledge  based  applications  and  their 
knowledge  bases  as  well  as  programming  projects.  The  KIT  Knowledge  Interface  has  three  top  buttons 
labeled  Knowledge-Of-The-Small,  Knowledge-Of-The-Large,  and  Knowledge-Of-The-Many  shown  in 
Figure  1.  Choice  of  any  one  of  these  buttons  results  in  display  on  the  screen  of  an  icon  command  win¬ 
dow  which  provides  a  detailed  partitioning  of  knowledge  within  each  of  the  top  level  partitions  --  to  be 

4  Habermann,  A.  N.,  Notlrin,  D.S.,  "The  Gandalf  Software  Development  Environment,’  Car¬ 
negie  Mellon  University.  Pittsburg,  PA,  January,  1982,  p.  1. 
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Figure  1:  The  KIT  Knowledge  Interface 


discussed  in  a  moment.  In  addition  to  these  three  broad  knowledge  partitions,  two  additional  selections 
are  provided;  Knowledge-Of-The-Moment  and  K^owledge-Of-Itself.  Knowlcdge-Of-The-Moment,  a 
term  coined  by  the  author,  provides  a  dynamically  constructed  knowledge  based  environment  which 
varies  with  a  user’s  choice  of  activities,  role  or  goals.  Knowledge-Of-Itself  provides  a  control  panel 
which  lets  the  user  instantly  reconfigure  the  knowledge  based  environment  or  change  his  profile. 


2J2.  Small  Grain  Knowledge  Partitions 

Selection  of  any  one  of  Knowledge-Of-The-Small,  Knowledge-Of-The-Large,  and  Knowledge- 
Of-The-Many  knowledge  partitions  results  in  display  of  command  windows  on  the  screen  with  icon 
commands  for  selecting  even  finer  subdomains  of  knowledge.  Selection  of  one  of  the  labeled  icon 
commands  on  the  command  window  results  in  display  upon  a  pop-up  menu  of  entities  within  the  asso¬ 


ciated  subdomain.  This  Entity  Display  will  vary  depending  upon  the  current  environmental  control 


settings.  The  user  can  either  browse  deep  within  a  knowledge  taxonomy  or  select  from  a  Command 
Display  commands  10  perform  operations  upon  one  or  more  entities  chosen  from  the  Entity  Display. 
The  process  of  browsing  is  initiated  from  one  of  the  top  level  entities  of  a  Small  Grain  Knowledge  Par¬ 
tition.  The  user  can  browse  through  knowledge  by  choosing  ore  or  more  entities  from  the  Entity 
Display  and  then  selecting  the  ‘DESCEND’  menu  choice.  This  choice  results  in  presentation  upon 
another  Entity  Display  menu  of  a  set  of  entities  related  to  the  previous  entities  to  a  specified  depth  and 
width.  The  browsing  process  can  continue  as  long  as  the  user  wishes.  When  the  user  finds  upon  an 
Entity  Display  one  or  more  entities  he  is  interested  in,  he  can  select  the  entities,  and  select  the  ‘DONE 
SELECTING’  menu  choice.  A  selection  of  entities  from  an  Entity  Display  determines  a  '  Knowledge 

t 

Context.  Once  a  Knowledge  Context  is  chosen,  the  Command  Display  will  appear.  Commands  shown 
at  any  time  upon  a  Command  Display  are  usually  specific  to  the  type  of  entity  selected  and  the  context 
of  its  use.  After  selecting  one  or  more  commands  from  the  Command  Display  the  commmands  are  pa- 
formed  in  the  sequence  chosen  upon  the  selected  entities.  Often  the  command  action  results  in  invoca¬ 
tion  of  a  subenvironment  of  the  knowledge  based  environment. 

23.  Entity  Displays 

The  'Entity  Display’  shown  in  Figure  2  is  a  dynamically  generated  pop-up  menu  which  displays 
one  or  more  types  of  entities.  An  Entity  Display  is  much  like  a  carefully  organized  index  or  the  table 
of  contents  of  an  encyclopedia  which  provides  structured  access  to  knowledge.  A  semantically  sound 
knowledge  base  is  usually  organized  within  taxonomic  hierarchies.  The  Entity  Display  employs  the 
relations  used  by  epistemological  structuring  mechanisms  of  the  knowledge  base  for  browsing  through 
knowledge.  Knowledge  is  organized  into  networks  connected  by  special  epistemological  level  structur¬ 
ing  relations,  such  as:  instance,  is-a,  has-compor.ent,  has-part,  subset,  memba-of,  etc....  The  labelled 
enuties  at  the  level  of  Small  Grain  Knowledge  Part. dons  are  generally  root  entiues  of  very  wide  and 
deep  entity  classes.  Membership  in  an  entity  class  i.;  defined  through  a  relatively  small  set  of  epistemo¬ 
logical  level  relations  which  connect  all  accessible  schemata  in  an  arbitrarily  large  and  deep  network. 


"  ■ » i  : '  i  n 

■tmlEcn 

I55B1 

KZ3XS 

iraatna 

u«t« 

QkLZHfll 

eexbh 

iroiBBi 

jAalatt**  ] 

I*"1*'*'  1 

tCB9H 

r.mnmw 

uum 

p=n  | 

^Z2£2j(l 

on 

[TTTVH 

dPTr!?* 


1 1  ^TTirr.1  r^—  ■  r,mrT  f  | 

Iritroriit  tna  tool  tntrrnrt  )yi»  WifHnaft  ' 


ENTITY  OiV LAY  X 


MiUmt 

CAEATE 


SELECT  ALL 
DONE  SELECTING 
DOWN  LEVEL 
ASOET 

itm<  amtupi  r»iri4i/«er 


tvNtUll 

NiHIU 

SmtCIJni 


|l£s _ 

f  I 

i^vflSryl — I 


rrrv\*rm 

rrms 


vrmm 


fTTrrim 


csmi^ 


(vnu 


tC3i 

orTTBM 


Figure  2:  A  Sample  Entity  Display 

Every  entity  created  in  the  KIT  is  a  schema  and  is  integrated  into  some  existing  netwoik,  which  means 
it  is  -  or  should  be  -  introduced  as  an  individuation,  instance  or  manifestation  of  some  other  entity. 

2.4.  Command  Displays 


The  ‘Command  Display’  shown  in  Figure  3  is  a  dynamically  generated  pop-up  menu  which 
displays  one  or  more  types  of  commands.  A  Command  Display  is  much  like  a  sophisticated  command 
and  control  center  which  provides  dynamically  structured  access  to  the  capabilities  of  a  complicated 
machine.  Many  software  systems  -  notably  most  operating  systems  -  provide  little  help  to  the  opera¬ 
tors  who  have  to  make  choices  about  how  to  use  the  software  system’s  resources.  An  operator  is 
required  to  make  dozens  of  decisions  about  how  to  use  a  system’s  resources.  Decision  making  within  a 
complex  environment  requires  knowledge  of  the  kinds  of  choices  possible  within  a  particular  context 
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Figure  3:  A  Sample  Command  Display 

It  is  possible  to  create  commands  and  command  selections  which  are  useful  and  specific  to  a  particular 
context.  In  fact,  most  commands  are  meaningless  out  of  context,  and  most  commands  only  exist  and 
make  sense  within  a  specific  context  The  context  of  a  decision  within  the  KIT  is  determined  by  a 
profile  of  the  user’s  role,  the  user’s  selection  of  environmental  control  settings,  and  the  Knowledge  Con¬ 
text.  These  factors  makeup  a  set  of  constraints.  The  Command  Display  menu  is  a  dynamically  gen¬ 
erate  set  of  commands  which  satisfies  the  set  of  constraints.  The  user’s  selection  of  one  or  more  com¬ 
mands  from  a  Command  Display  defines  a  Command  Context.  Taken  together  large  and  small  grain 
knowledge  partitionings  and  the  fine  grain  discrimintation  provided  by  of  Knowledge  Contexts  and 
Command  Contexts  reduce  the  complexities  of  the  environment  sufficiently  for  a  user  to  perform  com¬ 
plex  problem  solving  tasks  intelligently  with  relatively  little  or  no  training. 
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Any  number  of  entities  and  commands  can  be  queued  fcr  sm  ev  ..aC!. 
expect  to  be  passed  an  entity  as  an  argument  (actually  functions  ued  i  -ddi  command  are 
passed  the  selected  entity).  If  desired,  all  entities  or  all  commands  c.<j  >•*  s.-  eca  d  cnee  by  choosing 
the  ‘SELECT  ALL’  menu  selection.  The  ability  to  queue  actior^  .n  this  way  -.r.ymves  the  utilization 
of  the  user’s  time  and  helps  him  to  focus  his  attention  c’osely  upon  trsis  ?:  hard.  The  Knowledge 
Interface  attempts  to  minimize  keyboard  inputs  whenever  possnic  b;  ^.arlmizing  mouse  selectable 
choices.  It  is  rarely  necessary  for  the  user  to  type  ir.  the  name  of  an  en-cy  ..  except  for  when  he  first 
wishes  to  create  it. 


Figure  4:  Multiply  Queued  Command  Environments 


Figure  4  illustrates  how  a  sequence  of  commands  can  be  used  to  invoked  multiple  simultaneously 
invoked  command  environments.  In  the  diagram  only  one  of  the  tasks  environments  is  running  while 
the  others  are  paused.  Of  course,  in  addition  to  separate  command  environment  trvocauon,  the  inter- 


face  can  efficiently  perform  much  more  simple  tasks,  >uch  as  deleung  displaying  or  individuating  whole 
sets  of  selected  entities. 


2.6.  A  Knowledge  Rased  Integrated  Tool  Environment 

The  KIT  Knowledge  Interface  acts  as  a  flexible,  general  purpose  interface  for  a  wide  class  of 
users  to  many  kinds  applications  and  knowledge.  The  user  interacts  with  the  KIT  through  high- 
resolution  bit  mapped  displays  using  a  mouse  pointing  device  for  command  or  object  selection,  and  a 
keyboard  for  input  of  text  and  control  sequences.  The  KIT' employs  icon  commands  upon  icon  com¬ 
mand  windows  for  many  of  its  command  selections.  Several  forms  of  pop-up  windows  and  pop-up 
menus  are  used  for  displaying  schemata  and  command  selection.  The  knowledge  base  can  be  viewed 
and  manipulated  in  a  variety  of  graphical  and  textual  ways  provided  by  command  environments.  The 
user  is  abie  to  freely  move  from  one  command  environment  to  another  by  mouse  movements  and  input 
sequences.  The  KIT  user  interface  is  written  in  CRL  Command  and  Window  System  functions.  The 
KIT’s  network  graphics  are  generated  by  the  Knowledge  Craft  (TM)  Palm  Network  Editor,  the  Crystal 
Knowledge  Based  Graphical  Editor  or  the  Module  Development  Editor. 

Palm  Network  Editor 


The  Palm  Network  Editor  is  suitable  for  displaying  automatically  drawn  ’trees’  of  schemata  and 


relations. 


The  Knowledge  Based  Graphical  Editor 


The  KBGE  can  display  heunstically  drawn  'networks’  of  schemata  and  relations. 

Module  Development  Editor 

The  MDE  can  display  heuristically  drawn  networks  of  functions,  schema,  relations,  and  slots. 
The  MDE  uses  the  KBGE  for  its  command  structure  and  as  a  graphical  layout  engine,  but  it  uses  a 
powerful  set  of  heuristics  to  select  the  choice  of  entities  and  properties  it  displays.  It  might  be  con¬ 
sidered  a  ‘2nd  Generation’  KGBE. 
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The  Knowledge  Craft  Coconut  Schema  Editor  and  the  Pa'm  SuV-ru  Ur.  ;or  k  : 
manipulations  of  schemata. 

The  Coconut  Editor 

The  Coconut  Editor  provides  control  over  prompts  on  sicts  and  inpi ;  veIucs  .n  *  schema.  It  can 
control  the  sequence  in  which  schema  slots  are  filled  and  the  choice  cf  .'lot:  o  be  displayed  or  edited 

The  Palm  Schema  Editor 

The  Palm  Schema  Editor  permits  nearly  any  update  cr  edit  -  ever  of  meta  information  -  to  be 
made  directly  to  a  schema  within  a  Zmacs  like  editing  environment.  it  does  not.  however,  permit  the 
same  kind  of  value  formating  and  verification  control  as  is  provided  by  C  v  j-;  c. 

Any  number  of  interfaces  are  supported  by  the  KH.  Interactive  Dup.ay  V>  indews  arc  provided 
for  long  dialogues  with  the  user.  Interactive  pop-up  input  windows  ar  pro  \  or  ioi  the  user  to  respond 
to  input  requests  for  one  or  more  lines  of  text,  and  message  displays  arc  provided  to  display  one  cr 
more  lines  of  text  to  the  user.  The  CRL-OPS  (TM)  and  CRL- Prolog  (TNT  v*.  oil  benches  are  also  acces¬ 
sible  as  tasks  callable  from  within  the  KIT. 

3.  Knowledge-Of-Itself  Interface 

3.1,  Environmental  Controls 

Selecting  the  Knowledge-Of-Itself  subenvixonment  results  in  display  upon  a  icon  command  win¬ 
dow  of  a  set  of  icons  for  controlling  the  way  knowledge  is  presented  to  the  user.  Using  these  controls 
the  user  can  adjust  the  ‘depth’,  ‘width’  ‘granularity’,  ‘annex:'  and  'semantic  level’  of  knowledge  and 
commands.  These  environmental  parameters  can  be  used  to  alter  the  user’s  interface  with  the  KIT 
environment  by  increasing  or  decreasing  the  complexity  and  size  of  the  KIT’s  command  and  entity 
displays.  Figure  5  contair ,  a  sample  view  of  panels  which  provide  global  control  over  the  Knowledge 
Integration  Tool’s  behavior. 
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Figure  5:  Knowledge -Of-Itse If  Interface 


KIT  knowledge  bases  are  structured  witmn  a  formally  define  epistemological  suucrure.  The  KTT 
reflects  this  epistemological  structuring  of  knowledge  by  permitting  the  user  to  choose  the  ‘semantic 
level’  at  which  he  wishes  to  do  his  work.  The  semantic  level  is  one  factor  in  the  decision  the  KFT 
makes  about  the  kind  of  mechanisms  provided  to  the  user  for  manipulating  ihe  knowledge  base  Entity 
and  command  displays  will  vary  in  content  depending  upon  how  the  semantic  level  is  ,:ct.  The  imple¬ 
mentation.  logical,  epistemological  conceptual,  and  domain  semantic  levels  are  currently  supported  by 
the  KTT.  Additional  levels  may  need  to  be  created  to  add  even  finer  levels  of  knowledge  discrimina¬ 
tion. 

Semantic  Depth 

The  taxonomic  structure  of  a  knowledge  base  is  defined  b;  a  semantic  r.eiv. orl  whose  deni.i  is 
expressed  as  an  integer  number  which  describe.',  the  number  of  times  a  uxoncmic  relation  is  stepped 
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across  in  traversal  of  the  network.  The  user  can  control  the  nurr.br.  tf  lev  ::  .  tte  c.  •vw:.o:  network 
from  which  entities  are  taken  for  Entity  Displays  by  setting  the  scmanii  'iep:> 

Semantic  Width 

The  Semantic  Width  controls  the  manner  of  dispb>,  whether  the  disobv  t  -  j:s  the  structuring  of 
knowledge  or  colbpses  all  knowledge  into  a  single  display.  To  d  'pby  aul  react  j:.!e  endues  at  once 
the  Semantic  Width  can  be  set  to  wide.  To  display  entities  such  that  :  taxonomic  structure  between 
them  is  preserved  the  Semantic  Width  should  be  set  to  narrow. 

Semantic  Granularity 

Semantic  Granularity  controls  whether  semanuc  level  termers  re  csseti  "  the  display  of 
knowledge.  When  the  Semantic  Granularity  is  set  ‘.0  ‘Continuous’  rnr.o-Mh  rr.  -  s.  0;  provided  across 
semantic  levels,  and  the  user  is  able  to  view  knowledge  at  rcer-.i  semcm..:  levels  simultaneously. 
When  set  to  Discrete  only  knowledge  of  a  particular  level  is  displaced.  typtca.'  replication  user,  who 
usually  functions  at  the  domain  level  or  higher,  has  no  need  to  cross  epistemological  barriers. 
(Knowledge  Based  System  Designers,  on  the  other  hand,  need  knowledge  of  the  more  intricate  semantic 
structurings  of  the  knowledge  base  and  require  a  means  to  folio-.v  smooth  transitions  over  semantic  level 
barriers. 

Command  Granularity 

Command  Granularity  controls  whether  semantic  level  barrier-,  ar  crossed  in  the  command 
displays.  Continuous  or  Discrete  settings  are  provided.  When  the  Command  Granularity  is  set  to  ‘Con¬ 
tinuous'  a  smooth  transition  is  provided  across  commands  of  severai  semantic  levels.  When  set  to 
Discrete  only  commands  of  a  particular  semanuc  level  ate  displayed. 


3.2.  Environmental  Status 

The  Knowledge-Of-Itself  command  environment  provides  a  display  of  the  settings  of  environmen¬ 
tal  controls,  the  user’s  profile,  and  knowledge  about  the  knowledge  based  environment's  configuration 
upon  the  Environmental  Status  Display.  This  display  shows  the  current  state  of  the  Knowledge  Based 
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Figure  7;  Knowledge-01- TV 


parvuion  is  that  the  only  programming  emii  -  « in-  .1  ar  '  e  those  which  are  in  the 

workstation's  virtual  memory. 

4.2.  Selection  of  Programming  Commands 

Once  a  programming  enuty  has  been  selcctr J  *  c  e  ;  v.is  n.-.Rtpi.’aung  the  emits  is  pro¬ 
vided  which  is  appropriate  for  the  chosen  entity.  Oc.tr r  *  shows  sample  command  selections  available 
through  the  Knowledge-Of-The-Small  Command  L  rpl.i, . 

5.  Knowledge-Of-The-Many  Interface 
5.1.  Browsing  through  Activity  Models 

Ii  is  important  for  a  knowledge  based  environmem  to  serve  many  kinds  of  users  and  for  users  to 


be  able  to  use  software  resources  in  coordination  with,  each  other  The  Knowledge  Interface  provides 


Figure  8:  Knowledge-Ol-The-Small  Command  Display 


users  with  easy  access  to  highly  specialised  application  environments  through  the  Knowledge  partition 
for  Knowledge-Of-The-Nlany.  This  partition  possesses  a  representation  for  project  activities  Depend¬ 
ing  upon  the  semantic  level  of  interaction  which  a  user  chooses,  he  may  either  design  an  aruvuy 
representation  by  creating  a  model  foe  it  at  the  conceptual  level,  or  he  may  develop  a  domain  level 
application  w'thin  constraints  created  by  a  conceptual  model.  During  the  construction  of  a  r  iccptuai 
model,  a  model  developer  may  frequently  switch  from  one  semantic  level  to  another  in  order  to  after 
various  characteristics  of  the  environment  being  designed.  The  Small  Grain  KnowUvue  Partition  c?  thr 
interface  holds  Knowledge  of  Activities,  Agents  Objects,  Resources.  States  and  Goals  Figure  shovs 
a  view  of  some  of  the  top  level  choices  of  endues  accessible  *rotr.  wuhu  .he  *<:>*>  w*“dg'  -Of-The- 
Many’s  Small  Grain  Knowledge  Pi't.tion 


5.2.  Selection  of  Actiniv  Commands 


Figure  9:  Knowledge-Of-The-Many  Entity  Display 


Once  the  choice  of  an  entity  has  been  rriaoe  a  selection  of  commands  for  manipulating  the  entity 
should  be  provided  which  is  appropriate  to  the  kind  of  entity  chosen,  and  the  current  environmental 
control  settings.  A  manager,  for  instance,  is  likely  to  he  concerned  with  checking  on  the  progress  of  an 
activity  or  specifying  the  order  of  activates,  so  commands  are  provided  which  permit  managers  to 
review  the  PF.R7  chart  of  an  activity  network  or  to  modify  a  network  which  shows  a  sequence  of 
activities  An  acuvity  designer  is  more  like  to  be  concerned  with  specifying  relationships  between  pro¬ 
totypical  activities  and  resources  used  in  creating  or  transforming  objects,  so  commands  exist  to  provide 
him  with  specialized  environments  for  designing  various  kinds  of  activity  networks. 


Figure  10  shows  the  command  selections  available  through  the  Knowledge-Of-The-Many  Command 
Display 


Figure  10:  Knowledge-Of-The-Many  Command  Display 


6.  Knowledge-Of-The-Large  Interface 


6.1.  Browsing  through  Configurations 

It  should  be  possible  for  an  authorized  user  to  obtain  access  to  corporate  information  resources 
regardless  of  how  the  knowledge  is  distributed.  The  Knowledge  Integration  Tool  provides  access  to  a 
library  of  information  resources  through  the  Knowledge-Of-The-Large  interface.  The  Small  Grain 
Knowledge  Partition  of  this  interface  holds  a  library  of  Sites,  Projects,  System,  and  Components  from 
which  the  user’s  software  configuration  can  be  constructed.  Figure  11  The  diagram  below  shows  a 
view  of  some  of  the  top  level  choices  of  configuration  components  accessible  from  within  the 
Knowledge-Of-The-Large 's  Small  Grain  Knowledge  Partition. 


62.  Selection  of  Configuration  Commands 

Once  a  choice  of  configuration  components  has  been  determined  commands  for  cataloguing. 
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Figure  12:  Knowledge-Of-The-Large  Command  Display 


Tlje  dimension  of  the  partition  is  determined  by  natural  boundaries  within  the  modeled  knowledge,  by 
definitions  attached  as  meta-knowledge  to  certain  objects,  or  by  chronicling  of  information  about  the 
history  of  user  knowledge  and  command  context  choices  (i.e.  recent  Entity  Displays  and  Command 
Displays). 

The  Knowledge  Interface  provides  powerful  mechanisms  for  effectively  utilizing  resources  in  the 
knowledge  based  environment  Motivation  for  the  construction  of  this  interface  was  prompted  in  part  by 
analysis  of  the  Carnegie  Group’s  Knowledge  Craft  Interfaces  by  students  in  the  Advanced  Technology 
Center/Knowledge  Craft  course.  It  is  the  author’s  hope  that  this  interface  will  help  Knowledge  Craft 
users  to  utilize  Knowlege  Craft  more  effectively.  Screen  samples  of  a  prototypical  knowledge  based 
application  for  automation  planning,  which  was  rapidly  created  with  the  Knowledge  Integration  Tool, 
are  included  in  Appendix  A. 
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PROJECT  MANAGEMENT  ASSISTANT:  WHAT  HAVE  WE  LEARNED? 


Lt  Kevin  M.  Benner,  USAF  and  Louis  J.  Hoebel 
Command  and  Control  Software  Technology  Division 
Rome  Air  Development  Center 
Griffiss  AFB ,  NY  13441-5700 


INTRODUCT ION 


In  1983  Rome  Air  Development  Center  (RADC)  published  a  report  on  a 
Knowledge-Based  Software  Assistant  (KBSA)  [2].  This  document  brought 
together  key  ideas  on  how  artificial  intelligence  (AI)  could  be  used  in 
the  software  development  process.  Since  then  RADC  has  embarked  or.  the 
first  of  three  contract  iterations  to  develop  both  a  Knowledge-Based 
Software  Assistant  and  the  enabling  supporting  technologies.  This  paper 
focuses  on  one  facet  of  the  KBSA,  the  Project  Management  Assistant 
(PMA ) .  The  goals  of  the  PMA  are  to  provide  knowledge-based  help  to  the 
development  team  in  project  communication ,  coordination,  and  task 
management.  The  purpose  of  this  paper  is  to  describe  what  we  have 
learned  from  PMA,  which  concluded  in  December  1986.  Before  describing 
what  has  been  learned  from  the  PMA  effort  a  foundation  must  first  be 
laid.  This  foundation  consists  of  a  description  of  PMA  and  the 
supporting  technologies.  Following  this  will  be  an  analysis  of  what  we 
have  gained  from  the  PMA  effort  both  in  terms  of  life  cycle  activities 
and  supporting  technologies. 


SUPPORTING  TECHNOLOGIES 


The  supporting  technologies  fall  into  four  main  categories:  a  wide 
spectrum  language,  general  inferential  systems,  domain  specific 
inferential  systems,  and  system  integration. 

A  wide  spectrum  language  (WSL)  is  a  single  language  which  provides  the 
user  with  the  ability  to  capture  the  formal  semantics  of  the  system 
under  development  regardless  of  the  level  of  detail  (or  the  step  in  the 
development  cycle).  A  wide  spectrum  language  is  both  a  language  and  an 
environment.  It  must  provide  uniform  expressibility ,  regardless  of  vnat 
is  being  described  (ie.  requirements,  specifications,  code,  test  cases, 
project  management  policy,  etc).  Not  only  must  a  WSL  be  able  to  express 
these  objects,  it  must  do  so  in  a  way  wnich  is  consistent  at  al]  levels, 
both  syntactically  and  semantically. 

A  general  inferential  system  is  a  system  which  supports  reasoning.  In 
particular,  we  are  concerned  with  the  overall  efficiency  of  this 
reasoning,  how  to  capture  such  things  as  logic  in  inference  rules  and 
data  structures,  the  quality  of  explanation  generated  by  the  system,  and 
the  ability  to  apply  tnis  inferencing  power  to  specific  domains. 


Domain  specific  inferential  systems  extenc  general  infe  r  er.t  *  i*  systems 
to  include  aspects  unique  to  software  development .  This  '...ar  focuses 
on  the  knowledge  representation  of  software  development  objects  and 
inference  rules  and,  in  particular,  how  these  oojects  and  rilr-s  can  be 
formally  represented  and  used  for  further  reasoning,  ’-lore  specifically, 
this  category  can  be  broken  down  further  -  into  three  ~  ;r  categor  ies : 
formal  semantic  model  of  the  software  development  environment,  knowledge 
representation  and  management  of  software  development  objects,  and 
specializea  inferential  systems  which  incorporate  rules  that  have  been 
tuned  to  a  specific  problem  or  task. 

System  integration  deals  with  the  inherent  competition  uetween  facets 
and  how  a  technology  base  can  be  put  together  such  that  !  1  pnases  in 
the  software  development  process  are  supported  suf f  '  uientiy. 


PMA  OVERVIEW 


Work  on  tne  PMA  formalism  definition  an  1  construction  oc  a  prototype 
began  in  1985  [3,  4,  5],  Kestrel  Institute  was  th :  developer.  The  life 
cycle  goals  of  PMA  were  to  provide  knowledge-based  help  to  users  and 
managers  in  project  communication,  coord inat ion ,  aid  task  management. 

The  capabilities  of  PMA  fail  into  three  categories:  project,  definition, 
project  monitoring,  and  user  interface.  Project  definition  consists  of 
structuring  the  project  into  individual  tasks  arid  then  scheduling  and 
assigninc  these  tasks.  Once  the  project  has  beer,  decomposed  into 
manageable-  tasks,  it  must  be  monitored.  This  monitoring  is  in  the  form 
of  cost  and  schedule  constraints.  Also  included  in  monitoring  is  the 
enforcement  of  specific  management  policies  (eg.  DoD-Std-2167,  rapid 
prototyping,  K3SA ,  etc.).  In  addition-  PMA  provides  a  good  user 
interface  for  project  monitoring  an  1  project  definition.  This 
interaction  is  in  the  form  of  direct  g r  ies  'updates ,  Pert  charts,  and 
Gant*-  charts. 

The  above  capabilities  were  important,  but  would  be  expected  of  any 
project  management  tool.  What  sets  P;i\  «pa:  r  from  its  predecessors  is 
the  expression  ity  and  flexibility  of  the  PMA  architecture.  Not  only 
dees  PMA  handxe  user  defined  tasks,  bur.  it  also  understands  their 
products  and  the  implicit  relationships  between  them  (eg.  components, 
tas<3,  requirements,  specification,  source  code,  test  cases,  test 
results,  and  milestones).  Also  present  in  PMA  are  objects  unique  to 
programming-in-the-large  (ie.  versions,  configurations,  derivations, 
releases,  and  people). 

From  a  technical  perspective,  the  advances  made  in  PMA  include:  the 
formalization  of  the  software  development  objects  enumerated  above,  the 
development  of  a  powerful  time  calculus  for  representing  temporal 
relationships  oetween  software  development  objects  [6],  and  a  mechanism 
for  d  i  r  e  c  -  i  •/  expressing  and  enforcing  project  policy. 

PMA  ATT  SOP  PORTING  TECHNOLOGIES:  WHAT  HAVE  WE  LEARNED? 

The  results  of  tne  PMA  effort  have  been  twofold.  First,  PMA  has  pulled 
at  tne  supporting  technologies  such  that  they  have  advanced  the  state  of 
tnese  t-.:cnr;ol  >gi^3 .  Secondly,  PMA  has  made  progress  in  formalizing  how 


With  respect  to  advnpcec  r:  formalizing  project  ement  activity., , 

PMA  has  formalize!  r.ne  products  of  software  development  (eg.  tasks, 
components,  milestones,  requi  r  rnenrs,  specifics-.:  inns  ,  test  cases  etc.) 
from  a  project  management  perspective  and  provided  a  language  to 
describe  the  proofs  ,  oy  which  these  products  came  about.  In  the  current 
software  engineer  .r.c  1  :.ter  store  th.s  is  described  as  "process 
programming"'.1,.  Tnis  concept  nan  seen  a  part  of  pma  since  its 
inception,  though  not  reference  oy  unv  specific  name.  PMA  has 
demonstrated  that  a  software  project  '>n  be  described  formally  and 
reasoned  about . 

The  following  sections  wi.:  describe  toe  advances  in  the  support 
technologies  that  PMA  na.-  made. 

A  W  i  de  Soectrum  :.anr:ajt :  Th°  *Ss  used  for  the  PMA  prototype  is  REFINE. 
REFINE  is  best  describe'  as  a  programming  language  that  provides 

constructs  for  spec: :  i-rat  ion  :  n  a  variety  of  styles  <,eg.  functional, 
logical,  procedure'  a  nc  -eject  or  rented) .  These  constructs  include: 
user  defined  ofc  jec  :  c  .  a :  :•  a ..  set-theoretic  data  types,  constructs  from 
first  order  i .  g  i  •  tela ..  ions  defined  by  assertions,  transforms,,  a 

pattern  xr  .  ,  ..-.•a  conventional  programming  constructs  [8], 

As  well  as  providing  t.ne  acove  constructs,  REFINE  gives  the  developer 
the  ability  to  define  new  constructs  These  new  constructs  are  types  of 
assertions  used  to  maintain,  knowledge  base  integrity.  One  example  is 
CHECKING,  wh.cn  is  used  as  a  trigger  to  monitor  for  particular 

condition  As  l  and  then  f  lags  the  system  when  they  arise.  COMPLAINING, 

often  used  in  conjunctiui  with  CHECKING,  interacts  with  the  project 
manager  to  explain  what  has  gone  wrong.  MAINTAINING  is  another  type  of 
assertion  whicn  automatically  insures  a  given  condition  remains  true. 

Because  of  the  expr essibi lity  and  the  extensibility  of  PMA' s  W3L, 
REFluE,  PMA  has  demonstrated  that  a  WSL  can  handle  in  a  uniform  manner 
both  software  programming  c.r.structs  and  process  programming  constructs 
within  a  single  language. 

Dome : n  Specif  :c  Inferential  Systems :  PM  b '  s  impact  on  domain  specific 
inferential  systems  is  see-.  \n  its  character  1  cat  ion  of  software 
development  oojects  in  tine  PMA  knowledge  base.  This  consists  of  how  to 
represent  requirements,  specif icat .on,  code,  development  history . 
project  poi etc.  such  tnat  they  may  be  reasoned  about  from  a 
project  management  ?e  r spec five .  This  reasoning  consists  of  enforcing 
policy  'mere  accurately  an  act : vities  coordination  role1,  prej  ec: 
structuring,  task  a- ^  :g,.ment ,  t  a  ex  soheoul  inq ,  schedule  monitoring,  tasx 
monitoring,  and  cost  monitor  :ng  . 

■  'in  one  area  of  general  :nih  •  en  i  i  a! 
tren  done  reside  of  EBGA  and  PMA  took  a..v  a.ntane 
tnat  has  benefited  f  r  on  .MA  t  erearcr.  is  tnat  of 
rr.a  n  t  I  a  :  i  j-  n  . 

Tr.e  calculus  s  ..n  “rumutn  nf  James  Allen's  :  n  v  .  1  ci.v:  ’.us  for 
reasoning  ai-o  time  '  j  .  A.  Ion's  relational  algebra  has  1  <  i:  -~c  and 
is  fnererore  of  finite  sice.  The  expressive  power ,  : r  terms  of  time 
representation,  ot  PMA'.-  t.ne  ca.lcnl  us  .developed  by  Peter  Lad-..-.  •_  ernes 


Gene n.  I n fj.  •: ■? n 1_  J y n •_ 
s  y  stems  ,  m  s  o  n  *  o :  .  a  n 
of  that  work.  .ire  area 
time  r e p r e s e n t a t  i c n  a n d 


from  its  infinite  algebra  [6],  The  temporal  lOjic  pr.mi.  ves  are 
implemented  directly  in  REFINE. 

Some  of  tne  advantages  cited  by  Peter  Ladkin  of  the  Kestrel  tea.:  include 
the  capturing  of  the  metaphysics  of  time  and  presenting  a  natural  way 
for  representing  time.  Also,  the  representation  allows  for  the  joining 
of  seconds  into  minutes  and  days  into  weeks  or  montns  such  that  there  is 
a  linear  hierarchy  of  standard  units. 

System  Inte-u  ration:  Finally,  within  the  area  cf  system  integration, 
PMA ,  being  the  first  facet  on  contract  and  without  the  advantage  of  a 
common  framework,  relies  on  a  tightly  coupled  relationship  between 
facets.  Knowledge  base  objects,  which  would  have  come  from  other 
facets,  are  assumed  to  be  present  and  up  to  date  in  tne  PMA  knowledge 
base . 


SUMMARY 


Although  the  PMA  is  a  prototype  intended  as  a  technology  demonstration, 
it  will  be  used  at  both  RADC  and  at  the  Software  Productivity  Consortium 
for  experimental  purposes.  The  next  developmental  phase  will  be  to 
build  a  functional  implementation  of  the  current  research  and  to 
integrate  it  into  a  conventional  software  environment.  The  purpose  of 
this  is  two  fold:  1)  to  demonstrate  transfer  of  KBSA  technology  into 
the  operational  world  as  that  technology  comes  to  maturation  and  2)  to 
continue  work  in  AI  and  project  management  in  real  world  applications. 
This  work  will  begin  in  late  1987. 

This  initial  prototype  concentrated  on  providing  a  knowledge-based 
£ramewor<.  It  did  not  concentrate  on  interaction  with  the  underlying 
KBSA  support  system  such  as  policy  enforcement  for  version  and  access 
controls  of  ob]ects  developed  by  other  facets.  Nor  was  emphasis  placed 
on  a  common  user  interface  or  PMA  integration  into  a  standard  work 
env ; r  un.-ent .  These  latter  two  issues  are  important  for  user  acceptance 
and  ;:he  former  issues  are  related  to  the  overall  KBSA  development,  cost 
and  performance.  These  are  some  of  the  issues  which  will  be  explored 
a.ou  answered  in  the  next  PMA  development  and  its  integration  into  a 
:r  -vent  icnal  software  development  environment. 
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de  an  overview  of  the  Automated  Software  Development  Workstation  Project, 
to  explore  knowledge-based  approaches  to  increasing  software  productivity, 
■•••t  focuses  on  applying  the  concept  of  domain-specific  automatic  programming 
D-s'APS)  to  application  domains  at  NASA’s  Johnson  Space  Center.  We 
a  v-Tsion  of  a  D-SAPS  developed  in  Phase  1  of  the  project  for  the  domain  of 
it  ion  momentum  management,  and  discuss  low  problems  encountered  during 
mentation  have  led  us  to  concentrate  our  efforts  on  simplifying  the  process  of 
and  extending  such  systems.  We  propose  to  do  this  by  attacking  three  observed 
ks  in  the  D-SAPS  development  process  through  the  increased  automation  of 
lisition  of  programming  knowledge  and  the  use  of  an  object-oriented 
ient  methodology  at  all  stages  of  program  design.  We  discuss  how  these  ideas 
:  implemented  in  the  Bauhaus,  a  j  rototvpe  CASE  workstation  for  D-SAPS 


ent. 


1.  Increasing  software  productivity  through  domain-specific 
automatic  programming 

"'of:  w  •lr<'  development  is  an  increasingly  serious  bottleneck  in  the  construction  of 
<•.  mphx  automated  systems.  Increasing  the  reuse  of  software  designs  and  components 
has  i i :  viewed  a"  an  important  way  to  address  this  problem,  possibly  increasing 
pro  !’]••' i\ ity  by  an  order  of  magnitude  or  more  [9j.  A  promising  approach  to  achieving 
-<  1:  a  -■  a 'ability  i«  through  domain-sped  fic  automatic  programming. 


i.".  !'<■()  -i'll, n  nf  ,i  paper  to  appear  in  (lie  Proceedings  of  the  Space  Operations  Automation 
\\..ik'irv  I  h'li'ion  IX.  August.  1987  This  work  is  supported  by  NASA  Lyndon 
•  ■  •  hi,  | , . i  (  oiiiract  NAS  9-17766 


i Cunni n--pecific  :t i i  = . - 1 n ■  i ' C  programming  systems  iD-SAPsi  vo**  domu:i.  k i .•  w  •  • 

automate  ill"  r«.-n  neiufiit  of  a  pr-  -gram  description  (written  in  a  hkh-l>  1:1:1. 

language'  into  compilable  code  r.vrit’a:  in  .1  procedural  target  language'  1  . 
ran  be  li^t  i  1  1 1  :^i :  <.  •  I  !:  -’n  the  m<  >r*  traditional  doinain-indepcn  i>  m  ,  1  h  •  • :  i 

I'i'ogramining  system''  i ;  iutt  the  specification  of  the  program  is  in  a  domain-sp-vii'i-- 

language  accessi  1 .  i  <  to  an  end  user,  rathe;  than  a  formal  specife-ation  Inngiuu1.  o  .a.  t  in 

predicate  calculus  with  equality  •  .\ppiication  generators  of  the  type  used  in  !un  iic-s- 

report  generation  .  e.g.  !  us  anu  DBaSL-II)  are  examples  of  D-SAP^  in  whirl. 

refinement  process  is  complete!'  nut •  unatic  and  implemented  procedural!;  !u  .  Mrs 
complex  domains  ran  h"  r. audio!  if  the  user  is  allowed  to  interact  with  an  i  rush  tin 
refinement  pro'  -  -.-.  !  V-nuype  knowledge-based  systems  that  support  user  iiroa  a  -t  h  u, 

anu  whir:  v  irk  lor  practical  application  domains  have  been  successfully  develop*-.;  o-.g. 
Draco  16k  </>NIX  i:i..  and  K  BE  macs  [25  J. 

2.  The  Automated  Software  Development  Workstation  Project 

Since  the  fall  of  I9S5.  Inference  Corporation  has  been  involved  in  an  effort,  sponsored 
by  NASA's  Lyndon  B.  Johnson  Space  Center,  to  explore  the  applicability  of  domain- 
specific  automatic  programming  to  NASA  software  development  efforts.  Phase  I  of  the 
project  focused  on  the  development  of  a  D-SAPS  for  the  domain  of  Space  Station 
momentum  management  (19j.  During  Phase  1.  A  prototype  D-SAPS  was  -onstr.ieted. 
comprised  of: 

•  a  components  catalog  of  FORTRAN  subroutines  used  in  the  const  ruction  of 
Space  Statin  orbi'n!  simulations; 

•  a  design  catalog  of  programs  implemented  using  the  system; 

•  a  interactive  graphic,  1,  design  system  using  a  dataflow  specification  iatnrtmc 
for  c'-sign  editing  and  compments  com  posit  ion; 

•  rode  generators  for  romp,  iicnt  in!  -rfa'a's,  numerical  subroutine-  am;  ma'.:. 
pro-era  no-:  and 

•  rule- 1  -i-e,1.  <  x ;  -tt  that : 

u  in-.  p<  >s<- i  r e ; *1  n e 1 1 1  c  tit  -  f  1  unimpleiiiented  module'  in  t!e-  out 1  a 


s]i<vi!'icat  ion: 

.  fingc'd  inconsistencies  at  manually-specified  component  interfaces;  and 

:  Muf-o^ted  p; "^?i hie  workaround''  to  "patch"  inconsistencies  ( e.g. 
co"’f  linate  system  conversion  routines). 

The  -ystep.i  \va<  implemented  by  hand,  to  serve  as  a  model  for  the  implementation  of 
similar  ])-s.\r>  for  other  NASA  domains.  The  functionality  and  performance  of  the 
prot  ''yp-_  was  adequate  to  demonstrate  the  applicability  of  the  D-SAPS  approach  to 
*-of;  v.  development  at  NASA  JSC.  However,  our  experience  in  building  this  system 
md  ’>  to  agree  with  other  D-SAPS  developers  in  noting  that: 

•  "domain  analysis  and  design  is  very  hard"  [16];  and 

•  "domain-specific  systems  can  be  quite  useful  within  their  range  of 
application,  but  the  range  is  often  quite  narrow"  \‘l\. 

\\>  feel  that  these  two  issues  must  be  addressed  if  D-SAPS  are  to  play  a  significant  role 

in  future  software  development  environments.  Therefore,  in  Phase  II  of  the  project,  we 

are  attempting  to  address  the  bottlenecks  in  the  D-S.APS  development  process  that  lead 

to  these  observations. 

3.  Addressing  the  bottlenecks  in  D-SAPS  development 

W-  have  focused  on  three  bottlenecks  in  the  D-SAPS  development  process  that  were 
observed  during  the  development  of  the  Phase  1  system: 

•  developing  a  domain  language: 

•  d'^-ribing  design  refinements  arid  constraints;  and 

•  d'-s'ri him:  the  generation  of  target  language  code  from  a  sufficiently  detailed 

pr  .'gran,  description. 

■A  e  ;  oil.  •  -•  iuee  the  effort  spent  on  each  of  these  tasks  by: 

•  tin  programming  knowledge  acquisition  process;  and 

•  .hje.-i--  re  nt' d  development  methodology  at  all  stages  of  the 

■  •  -.a.  b*si £ ij  pr  i'-'-ss. 

■  ■  :  i  ’  ’ :  . ;  •  I  •  : :  i  e  1 1  *  i  n  g  a  know  le  ige-based  D-SAPS  de  .eiopnieut  workstation. 


3.1.  Automating  the  programming  knowledge  acquisition  process 

:  ’  ■  ••  •  ::  •'  a.  ,:.g  _ a  :  r  •  ••••••  <  '  : ; .  i "  '  V.  * |n-  •  4  Mi  >\\  require  .  : . 

•  \ .  •  ie-  M:  •u  ,■  . ;  a .pi: -3 a  ■:  •  •  ••  •  •  ■  1.1  -cl*-  r  '.:a plm  !  I  .  ami  !  ::>• 
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'(•AR  I'J  s \ s t 'in-,  i m i ■  i <:•  m ■  - ! : :  '  :  using 


:  !:■■  APT  f\’  -rt  1  •  1 1  i  1  *  1  i  t :  •••  •  !!,.  him  a:  mite.-t  ur--  ailows  u>  to  <  mga  ui  jrsign 

i. ; :  v.  f  •  ig-  a  :,f . A  .  •  •!’  spnc-s.  representing  pr-  .'"am  iesign  » asks.  Each 

■  i >  1  •  ■ : •  i  spa  •  V  i  .■  «  ■  • ,!'  operators  for  performing  the  task  represented  !>y  tin 
space,  h  •  Baumum.  a  problem  space  is  associated  v-ith  each  program  description 
t ;iat  tic  system  has  in  its  knowledge  base.  The  ’.ask  repr<  sauted  by  the  pr< •I'ictn  spa^c 
is  t lot'  of  refining  the  program  description  until  it  is  sufficiently  detailed  to  allow  a  code 
eem-rator  to  translate  i(  into  •<. de  in  the  targe:  language.  The  design  process  in  the 
Bannaim  occurs  in  the  following  way: 

1.  Select  the  initial  design  problem:  the  user  copies  and  edits  at;  initial 
piv.g  am  description  from  the  set  of  program  description*'  in  the  knowledge 
base  using  a  structure  editor,  making  it  the  current  description.  The  initial 
problem  space  is  that  associated  with  refining  this  description. 

lb  Propose  operators-  the  Bauhaus  determines  what  operators  are  applicable 
to  the  "urrent  description. 

3.  Choose  an  operator:  Bauhaus  chooses  an  operator  from  the  prop'.  :•••:! 

"dug  operator  preformi^s  and  constraints  associated  with  th<-  problem 


'•nf-  ; •  r •  ;  ■  .rim ace  inconsi-meni  '  1 2 1 .  Thi-  interac1 ;  m  *  a  I 

n  - : 

'll  '  oi’.  p  I-.  . ;  i<  |  ;  .e:  at  I'  b  ,!i  m  :  a,  ]  .V;  !  : 


am:  irnpn 

request 

>•' :  when  t 

a  :  i  e  1 1  • 

lie  systi-ii, 

u  * 

lie  system 

on*  of 

'  "•  -  f  »rin- : 

•  - 

i *  : - >  -  -i, 

- '  i"  i.un-s  »!**••  t  iii'Mt'itf  of  ui  '*.  ■  1 1  ■  i .  1 .  •  *  :!  i'i'i  ..  u,. 

I  1 1  ••  Him  in-  '  r  ,t  i.i'ieri"  ’hat  -vnt  lu-si/t- !  ;  * .  .  1 1 1  • . .  ■  : .  r.ift*-:. 


•  'll'  1 1 "< •  i  edit'  the  current  program  description,  in  wlii - h  cast-  we  return 

.  v  t>  j  ,  •  > 

I.  Apply  the  chosen  operator:  the  Bauhaus  applies  the  chose;!  operator  to 

’  i  *•  :  '!  •  ; 1 1  ■i'-'.-ription.  The  operator  may: 

•  r . into  problem  subspace. 

•  :  if  current  description. 

•  'iu;:  b  t  iiat  the  task  for  the  problem  space  is  complete,  or 

•  '•! z ; : ; 1 1  'hat  the  task  cannot  he  successful  completed. 

A  s  i r  : .  r •  * t  urn  to  step  2. 

The  i’s'mn  process  terminates  when  the  top-level  task  of  refining  the  initial  program 
d'-s-ripti  n  is  successfully  completed.  This  occurs  when  the  description  is  detailed 
enough  •  allow  the  generation  of  target  language  code  to  occur.  Given  this  problem- 
s' ■■ivii.g  architect  lire,  we  now  discuss  the  knowledge  acquisition  mechanisms  used  to 
obtain  th"  descriptions,  operators,  operator  preferences  and  constraints  used  in  the 
design  process. 

3.1.1.  Acquiring  descriptions 

Our  representation  of  domain  objects  and  operations  uses  a  description  language, 
implemented  in  ART  schemata,  that  is  similar  to  KRYPTON  (l7j.  New  descriptions  of 
dr. main  objects  and  operations  are  created  from  existing  descriptions  using  the  copy- 
and-e  lit  technique  espoused  by  Lenat  in  the  CYC  system,  [13]  and  are  placed  in  the 
appro!  riate  location  in  a  subsumption  hierarchy  by  an  automatic  classifier  [8],  This  use 
:  de-o-ri]  ; ion  copy-and-edit  together  with  automatic  classification  reduces  the  effort 
require-!  t-  extend  the  domain  language  used  to  describe  systems,  by  fostering  reuse  of 
'".T-ting  i  .main  languages  in  the  creation  of  new  domain  languages.  Using  a 

-ub-u:  ;  tbit,  hierarchy  <>f  descriptions  as  the  organizing  framework  for  the 
'  o'  f  •!  yet-  and  operations  supports  user  access  for  copy-and-edit  actions 
•••  •  •  .i.-i.\  -  ref.  .rm illation  browser  similar  in  design  to  \RGON  ]  1  *<! . 

: nnulaii  a  will  permit  a  naive  user  of  the  Bauhaus  to  find  a  description 
■  '  i  v-au  lit  action  more  easily  than  using  a  tradition  query  mechanism 


4.  System  status  and  limitations 

l:  .•  j  u.  f  Bnulmus  i<  currently  unut  rwa>  c  - .  i :  \KY  j  g.  on  a 

"■  ,  ••  machine  u n< i«*r  tin*  Genera  7.1  < • : i \  iroiimen: .  Or  ; ■  •!  for  V'. 

■  i  ami  .7  r;.r>  management  is  provided  l>y  the  Symbod  ■-  Via  progranmdu- 

•:'ir  .  V  !  .1  w;.  HIST.  ART-based  re  presen  tat  ions  !’••.;•  •ie-cri'-:  ,•  ms.  operator''. 

. era*  :  rei,  e-  and  m-u  raints  have  been  designed.  :  lie  problem-solving 

a and  ! aYc  know  ledge  acquisition  algorit  ii  ms  have  l>eeii  designed  and 
ir.ipi- .!.  and  the  target  language  reusable  components  li:>:a;\  has  i >ee n  selected. 
The  -a..;-  -m  efface  is  currently  under  construction,  and  the  donut’ n  auahsis  for  the 
d  -*  m  ■  tot  rati  domain,  orbital  flight  simulation,  is  underway.  We  plan  ■  •  •  d  •iiionstrate 
ti.e  im-  ■  1  the  Bauhaus  in  the  const  ruction  of  a  D-S.VIY  for  t  hi:,  domain  in  the  first 
quart c-  f  i 


it.  :  !.••  e;.rre!:i  design  ,>f  the  Bauhaus.  t here  are  a  number  of  issue'  reh-vunt  to  D-SAPS 

t  im'  w  "  do  not  address; 

•  Lifecycle  issues;  the  Bauhaus  is  only  useful  as  a  programming-in-t  lie-small 
••avir  ’ament,  and  ignores  programming-in-t iie-large  issues  (e.g.  version 
■ontr  'O.  These  would  have  to  he  addressed  in  a  production-quality  system. 

•  Persistent  object  bases:  the  Bauhaus  has  no  provision  for  saving  session 
st.-p*  in  a  more  sophisticated  manner  than  simply  saving  changes  out  to  a 
t-xt  file.  We  are  looking  to  object-oriented  database  management  systems  to 
pr-.vid*  an  answer  here  j-ll. 

•  Automated  algorithm  synthesis:  the  Bauhaus  will  always  reach  an 
;::;t 'I."*-  if  a  programming  task  requires  algorithm  design.  However,  the 

id:  ure  -houid  be  extensible  to  encompass  this  kind  of  problem  solving 

•.r..  ■'(■•■  the  work  by  Steier  on  the  Cypress- Soar  and  Designer-Soar 
Ye-'  "i'litii  design  systems  [21;). 


5.  Conclusion 

!  '  Yen  i i : i ■  -h  : ; i : : i n - j > * ■  < •  i f i r •  automatic  programming  is  a  viable  approach  to 

1  '  I  ii-t  i  vit  v .  To  make  this  approach  a  practical  one.  the  task  of 

:  :,  ;  1 ; i o  I  )- W\PS  niuv  be  made  simpler.  As  described  above,  we  plan  to 


•lie  knowledge  acquisition  and  Ttwap-  engineering 


in**!  ii.  us-d  in  ..••.'li-:  ;-u*-l ! uu.  I)-SAI  (  mr  : i!t  i goal  i-  :t  ] >ro» i u •  ;:i:» !i ■.  \ 

-\v;  -in  fni,r:  h  ■  1  •<  . !  :i>  :il:  " :« |  »i»!k  at  !•  >:>  u.*  •  1 1  ■  •  >  :.tor  genera!  ,.e.,  a 

;;u . 'u  ]••  !a-  based  •  1 1 \  i m :  1 :  for  i  he  construct  ion  of  special-purpose  systems  l  a  ;  in 
_ : h j i ' a ’  i .  n  of  application-'  softw  are  i*y  end- users.  Such  a  system  could  he  available  ti 
'vsi-aiis  analysts  and  designers  in  a  DF’  'MIS  <  eanizat  ion  lor  use  alien  an  application- 
program  mins;  task  occurs  frequentiv  enough  to  merit  t  lie  creation  of  a  D-SAPS. 
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ASDL  -  AN  INTELLIGENT  ACQUISITION  SUPPORT  TOOL 
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ABSTRACT 

This  paper  describes  ASDL,  an  experimental  prototype  for  an 
Al-based  acquisition  support  environment.  Acquisition  analysts  and 
system  engineers  will  employ  ASDL  to  represent  and  maintain 
functional  requirements  and  other  aspects  of  system  specifications 
in  the  form  of  symbolic  models.  These  symbolic  system  descriptions 
are  constructed  by  copying  and  adapting  (historical)  models  of 
previous  systems  or  elements  from  a  library  of  generic  function, 
component,  and  system  templates.  Analysis  capabilities  are  under 
development  to  assist  users  in  evaluating  the  economic  and  technical 
feasibility  of  system  models.  Specifically,  facilities  are  being 
implemented  to  represent  and  dynamically  simulate  behavioral  aspects 
of  systems  and  to  compute  system  sizing  estimates. 

INTRODUCTION 

Government  acquisition  programs  follow  a  standardized 
development  cycle,  from  concept  exploration  and  formal  system 
requirements  definition  through  design,  implementation  and  field 
operation.  As  systems  become  larger  and  more  complex,  maintenance 
and  analysis  of  the  information  needed  to  characterize  systems 
through  the  acquisition  cycle  becomes  increasingly  difficult  and 
costly. 

A  variety  of  computerized  automation  tools  already  exist  to 
support  system  development  activities.  Unfortunately,  these  tools 
are  not  easily  integrated  because  they  operate  on  different  kinds  of 
models.  Documentation  tools  manipulate  simple  text  and  graphics. 
Simulators  and  design  tools  model  system  structures  and  relations 
(e.g.,  connectivity,  data  and  control  flow).  Costing  and  sizing 
tools  manipulate  algebraic  attributes  for  system  components.  These 
models  are  often  implicit  (i.e.,  neither  visible  nor  explicitly 
manipulable) ,  and  are  rarely  extensible  to  represent  information 
that  lies  outside  of  a  given  tool's  immediate  scope. 

MITRE's  Automated  System  Development  Library  is  a  prototype  for 
an  Al-based  tool  designed  to  assist  Government  personnel  in  early 
phases  of  acquisitions  (i.e.,  through  preliminary  design).  The 
objective  of  ASDL  is  to  assist  acquisition  analysts  and  system 
engineers  to  represent,  maintain,  and  analyze  symbolic  models  of 
system  specifications.  ASDL  models  depict  system  architecture, 


functionality  and  behaviors  within  a  single,  explicit  represen¬ 
tational  framework.  Extensions  to  encompass  system  design  factors 
(e.g.,  estimated  size  and  complexity,  performance  needs  and 
projections,  maintainability,  reliability,  and  similar  engineering 
constraints),  are  also  being  developed. 

The  ASDL  prototype's  maintenance  capabilities  include  creation, 
modification,  browsing,  and  storage  of  system  description  models. 

The  analysis  utilities  under  investigation  will  help  acquisition 
analysts  to  assess  the  technical  and  economic  feasibility  of  systems 
as  depicted  in  these  models. 

This  paper  provides  an  overview  of  ASDL.  First,  the  tool's 
library-based  approach  to  system  model  construction  and  current 
representational  capabilities  are  described.  Behavioral  modeling 
and  the  architecture  of  the  simulator  shell  are  discussed  next. 
ASDL's  current  analysis  capabilities  and  user  interface  are  then 
reviewed,  followed  by  a  sketch  of  planned  enhancements. 

BACKGROUND 

This  section  reviews  the  kinds  of  information  called  for  by 
DoD-STD-2 167  for  specification  products  in  early  phases  of  system 
acquisitions.  The  objective  of  ASDL  is  to  capture  these  aspects  of 
system  descriptions  in  explicit  structures  in  symbolic  models. 

The  System/Segment  Specifications  (A-Specs/SSS) ,  produced  by 
Government  customers  (and/or  agents  such  as  MITRE),  defines  a 
system's  mission,  operational  modes  and  functional  requirements. 
Requirements  for  interfacing  to  existing  systems,  quantitative 
performance  needs,  and  other  design  constraints  are  also  delineated. 
Design  constraints  include  quality  factors  such  as  reliability  and 
maintainability,  security,  logistics,  and  operating  environment ( s ) . 

In  source  selection,  the  Government  evaluates  proposals 
submitted  in  response  to  the  functional  requirements  specification. 
Proposals  outline  technical  approach,  size  and  cost  estimates, 
engineering  and  management  methodologies. 

Winning  contractors  submit  a  sequence  of  specifications  and 
design  descriptions  for  Government  approval  before  implementing  a 
system.  Software  Requirements  Specifications  (B-Specs/SRS)  allocate 
functions  among  particular  hardware  and  software  subsystems  in  a 
high-level  system  architecture  and  specify  data  flow  relations  among 
those  subsystems.  The  Software  Top  Level  Design  Document  (STLDD) 
presents  Preliminary  Design  interfaces  and  protocols  between 
software  and  hardware  subsystems.  Software  Detailed  Design 
Documents  (SDDD)  specify  data  structures  and  data  and  control  flows 
within  subsystems. 
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LIBRARY-BASED  SYSTEMS  MODELING 


New  systems  are  seldom  totally  unique;  typically,  t  hcv  incor¬ 
porate  existing  capabilities,  whole  systems  and  system  fragment*-, 
enhancing  or  adapting  borrowed  items  as  necessary.  aSD!.  retlects 
this  fact  by  incorporating  two  libraries  containing  reuciole  models 
and  model  elements  to  facilitate  the  generation  cl  r.y.  system 
descriptions. 

The  first  library  is  being  filled  with  histor  ca!  s-ster 
descriptions  -  ASDL  models  for  previous  acquisition  programs  and  for 
completed  (early)  phases  of  ongoing  system  development  efforts. 
Current  contents  include  model  fragments  for  system  specifications 
created  or  reviewed  by  MITRE. 

The  second  library  is  being  populated  with  gene*.  '  c  :>r 
prototypical  system  functions  and  components.  ASDl-'s  current 
library  focuses  on  Communications,  Command.  Control,  crl 
Intelligence  (C^I)  systems,  modeling;  stancard  C  I  functions 
(e.g.,  data  base  services,  signal  and  message  processing);  system 
components  (e.g.,  sensors,  communications  interiacss,  computers.;; 
systems  (e.g.,  communications  networks);  data  objects  (e.g., 
messages,  signal  pulses,  computet  system  account  profiles);  and 
systems  personnel  (e.g.,  operators,  maintenance  staff,  users). 
Alternative  generic  libraries  can  be  inserted  to  support 
template-based  modeling  of  different  system  engineering  domains. 

Figure  1  displays  a  portion  of  the  ASDL  generic  library, 
organized  as  a  frame  hierarchy.  Each  tree  node  designates  an 
individual  frame  template.  The  lines  connecting  nodes  in  the  figure 
represent  class-subclass  relations  between  library  frames. 

ASDL  models  are  expressed  in  a  frames  language  (KEE).  Frames 
represent  systems,  components,  functions,  and  the  relations  that 
hold  between  them.  Frame  slots  depict  attributes  descriptive  of 
object  classes,  such  as  component  size  and  complexity  factors  and 
physical  or  performance  characteristics.  Figure  2  displays  a 
generic  library  template  for  radar  systems. 

Slot  facets  describe  attribute  value  cardinality,  units  and 
legal  values  restrictions.  The  legal  values  descriptor  for  the 
Baud. Rate  attribute  of  the  Communications .Device  component  class, 
for  example,  is  (ONE. OF  300  1200  2400  ...).  ONE. OF  is  a  term  in 
KEE's  Boolean  "ValueClass"  language  interpreted  as  "at  least  one 
of."  The  value  of  the  units  facet  for  Baud. Rate  is  "bits  per 
second."  Additional  ASDL  facets  hold  text  strings  for  supplemental 
explanations  of  attributes  or  attribute  values  and  for  references  to 
relevant  Government  standards  documents.  Explicit  representation  of 
such  information  in  a  standardized  format  facilitates  the 
development  of  automated  analysis  capabilities. 


Figure  1.  Portion  of  ASDL  Generic  Modeling  Library 
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Developmental  system  models,  or  knowledge  bases,  are  generated 
through  a  simple  copv-and-eri i t  strategy.  Users  select  appropriate 
frames  from  ASDL's  libraries  and  copy  them  into  the  new  model 
workspace.  Copied  templates  and  system  tragments  are  then 
customized  to  reflect  the  exact  content  of  the  system  description 
under  development.  Customization  proceeds  by  supplying  values  to 
existing  slot  attributes  or  by  defining  new  attributes  and  then 
specifying  values. 

Figure  3  displays  a  frame  for  an  SSS  for  a  radar  system 
customized  from  the  generic  template  shown  in  Figure  1.  Note  that 
the  line  identifying  the  slot  name  (e.g.,  "Member  Slot:  BANDS  from 
RADAR-XYZ"),  indicates  the  source  object  (viz.,  RADAR-XYZ),  for  the 
slot  value.  Sometimes  values  are  inherited  from  Library  templates 
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(e.g.,  RADAR- SYSTEMS ) .  Note  also  the  unfilled  slots  -  many 
attributes  do  no.,  receive  values  until  well  into  the  sequence  of 
contraotc’  ,  oec  i  f  ic.ations  (e.g.,  descriptions  of  network  protocol 
suites;  . 

After  library  frames  have  been  customized,  relational 
connections  between  function  and  component  frames  are  specified. 
ASDL's  predefined  relations  include:  data  and  control  flow; 
hardware  and  software  interfaces  (internal  and  external);  structural 
and  functional  decompositions;  allocation  of  functions  to 
components;  and  mappings  of  functions  across  system  models.  Figures 
4b  and  5h  show  instances  of  functional  and  structural  decompositions 
of  functional  areas  and  subsystems  depicted  in  figures  4a  and  3a, 
respectively.  Users  can  define  additional  relations  by  specializing 
(i.e.,  creating  subclasses  of),  existing  relation  templates  in  the 
generic  modeling  library. 

System  architecture  is  represented  via  structural  connectivity 
relations.  Specifically,  interface  relation  instances  connect 
instances  of  customized  system  components  (or  systems).  Component 
instances  are  linked  rather  than  classes  because  acquisitions 
typicaLly  require  multiple  copies  of  system  components  (e.g., 
workstations),  and  of  whole  systems  (e.g.,  at  multiple  sites). 
Figures  4a  and  b a  display  the  radar  system's  functional  and 
structural  interfaces.  The  darkened  boxes  indicate  components 
external  to  the  subsystem  being  defined. 

Many  relational  connections  between  system  elements  are  too 
complex  tc  bf*  represented  by  simple  "pointer"  relations.  Consider, 
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Figure  3.  Radar  Application  System  (Customized  Library  Template) 
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state  into  a  systm  its  subsystems  and  their  structures,  ana  the 
data  objects  that  a  sv  ; e:r  processus.  ASDL  includes  mechanisms  for 
representing  and  s f mu  1  a c . re  nf.se  dynamic  system  function  behaviors. 

Briefly,  ASDL*  ?  ‘ 1 r.u1 at  or  shell  consists  of  frames  representing 
a  synchronous  c.ock,  a  s:  ■•■•1st  ion  manager,  a  scheduler,  and  a  test 
s  enario  generator.  Tin.  simulation  mechanisms  are  driven  by 
object-oriented  proc  .aura:  attachments,  which  are  implemented  via 
clots  in  KEL's  hvbr :  d  ir.imer,  language. 

Users  construct  tie  ha  v;  oral  system  models  by  supplying  the 
ml  lowing  ingredients :  a  uescnpt  ion  of  flows  between  system 
functions;  a  desc  r  1  pt  ic  >~  of  system  prioritization  and  scheduling 
algorithms*,  and  description::  of  function  actions  or.  data  objects 

and /or  the  model  system  md  its  components. 

Functional  flow,  mecrv  sequencing,  branching  and  1  oopi  ng 
relations  between  j/stem  tuner  ions.  Branching  and  looping 
conditions  specify  combinations  of  system  and  data  object  attribute 
••a  lues  (  e  .  g  .  ,  opera  t 1  ana  !  mode;,  target  priorities),  that  determine 
ticw  ( e .  g .  ,  whether  at  rack  is  stored  or  both  stored  and  displayed). 

ASDL  will  support  modeling  of  both  concurrent  and  sequential 
processes.  System  tor  component  server)  processing  priorities 
consist  of  queue  sort i ng  c»ndi tions.  Examples  include 
F 1  rst-I n-F  1  r st-Cut  and  rank  ordering  based  or.  data  object  type 
'.e.g.  ,  command  vs,  pack),  or  attribute  values.  Concurrency 
modeling  in  ASDL  depends  bo:,i  on  functional  flows  and  on  resource 
allocation  data  -  server  r  urr.oe  r?  and  their  nature  (e.g. ,  single  vs. 
multichannel)  and  fur  ut  i  or.  t-havior  requirements  (i.e.,  what  servers 
are  spec i f i ed  ) . 
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tunc:  :■  r.--  such  as  operational  mode  switch  command  .  •  date 

processing.  tor  car y  acq«isit:  on  models,  be  Si,  .  :o-  c  j .  i; 

consist  :  changes  to  values  of  attributes  to-  -vst or  -  >  c  . " 

(e.g.  .  component  s ,  data).  More  complex  actions  can.  tin  .  ~c  depicted 
(  e  .  g  .  ,  3 -ting,  collating,  correlating).  AS  PL  is  he  ng  equ ..  peed 
with  .!  nased  interface  for  declarative  spe>.  1 1  i  t  1 1 .  or  o* 

beha .  r  ;  out  explicit  programming  will  bo  :-:qt.r>-o  to  -epresent 
more  .  .  t .  s  t .  ca  ted  function  actions,  such  as  spec'."-'  >  iir..iJHS  or 

st lav  screen  mock-ups. 

behavioral  model  is  exercised  by  loading  test  scenarios 
(sequences  ot  exogenous  events)  into  the  sirvlator  shell •  Examples 
of  vs:  events  include  signal  trains  cr  messages  !r e n-  injected 
thro-.-h  external  system  interfaces  and  simulated  u»et •  i  tie  ted 
comn..it.G  sequences.  Given  these  stimuli,  the  neh-.vrora,  simulation 
generates  ( endogenous )  events,  represent ing  applications  c£  system 
functio  is  to  data  objects  and  model  system  responses  .  ~  -omr.anu 

Af  ’  a  test  scenario  is  loaded  into  the  model  system  knowledge 
base,  tne  simulation  manager  initializes  the  clock,  and  scheduler  and 
initiates  the  main  control  loop:  the  cl  nek  is  advanced,  timely 
events  are  injected  into  the  simulator  and  pr.oc  itiutx the 
scheduler  allocates  events,  executes  function  bel'u  'tors ,  and 
determines  successor  events.  If  explicit  component  iss  gnments  have 
been  made  for  functions  (e.g-,  in  the  SRS> ,  .the  scneo-l  *- 
automat  leal  1 handles  servers  assignment  ’  .  1  -<■>  :r  *  and  rs  •’  ises  and 
event:  queueing. 

It  is  important  to  note  that  ASDL  model-'  O'  ...  ts  .  1 
directly:  the  simulation  of  function  sex  i  ns  -  -  nr  .  •  •  > • 
executing  procedures  attached  to  model  s  • «.  t  rt  :  nr...  i  r  -  \ 

explicit  behaviors  are  ascribed  directly  t 
systems  and  system  components .  Instead,  ;  ur  •  •  a 
create,  modify,  or  destroy  such  mode!  fl  -m«_r 
standard  simulators  ignore  functions,  ,s  -  -  ,-t 

wit::  mod'-;  system,  component  .  and  da  a  •>  a 

A>h:.’s  approach  was  dictated  fcv  t  r,<_  ■*> 
beta.'  -r-  tor  acquisition  stages  wr. .  .-  -  •  • 
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Alternatively,  detailed  behaviors  can  be  prescribed  in  the  contex' 
of  specific  system  architectures.  ASDL  test  simulations  na'.e  beer, 
written  for  portions  of  military  communications  and  radar  systems. 

As  the  acquisition  cycle  progresses  into  design  phases,  svste* 
architectures  and  behaviors  of  subsystems  and  their  components  are 
defined  in  increasing  detail.  Function-oriented  simulation  becomes 
cumbersome  and  unintuitive.  Accordingly,  ASDL  will  either 
incorporate  or  interface  with  an  object-oriented  simulator  too. 
extend  its  applicability  to  later  stages  of  acquisition. 

ANALYSIS  CAPABILITIES 

ASDL's  library  elements  include  sizing  and  complexity  tac'ors 
that  enter  into  early  acquisition  studies  of  economic  feasibility 
(Figure  6).  Users  can  construct  system  models,  assign  values  to 
components  attributes  (e.g.,  sizing  descriptors),  and  compute  system 
sizing  profiles  that  can  be  used  as  drivers  to  (external)  costing 
tools  such  as  COCOMO.  ASDL's  initial  profiling  utility  totals 
estimated  source  lines  and  reusable  lines  of  code  from  all  software 
component  instances  in  a  system  model.  More  sophisticated  methods 
are  being  explored. 

ASDL  performs  simple  (i.e.,  syntactic),  kinds  of  completeness 
testing.  It  can  verify  that  functions  are  exhaustively  allocated 
among  system  components  (B-Spec/SRS)  and  that  functional 
requirements  (SSS)  are  accounted  for  (i.e.,  traced),  in  subsequent 
acquisition  models  (Source  Selection,  SRS,  STLDD).  Additional 
completeness  checkers  (e.g.,  for  connectivity  and  decomposition 
relations),  are  being  investigated. 

ASDL  utilities  support  users  in  specifying  and  simulating 
function  flows  and  behaviors.  Users  can  manually  analyze  the 
resulting  flow  structures,  behaviors,  and  simulation  traces  to 
uncover  omissions,  ambiguities,  and  inconsistencies  in  behavioral 
aspects  of  system  descriptions,  (SSS  Source  Selection,  SRS). 

The  simulator  shell  can  be  used  to  gather  quantitative 
performance  data  as  well  as  to  study  qualitative  system  behaviors. 
Each  function  behavior  can  be  associated  with  either  a  numerical 
time  interval  or  a  user-specified  functional  expression  which  is 
evaluated  in  the  simulation  environment  when  a  function  behavior  is 
actually  executed.  User  "time  expended"  functions  can  reflect 
performance  impacts  due  to  system  loads,  server  speeds,  data  object 
size,  or  other  model  system  variables. 


Figure  6.  Component  Sizing  Attributes 
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USER  INTERFACE 


ASDL's  intended  user  community  is  comprised  of  acquisition 
analysts  and  systems  engineers.  This  audience  is  assumed  to  be 
familiar  with  systems  and  the  acquisition  process,  but  not  with  AI 
concepts  or  programming  skills.  Interface  design  is  obviously 
critical  to  the  tool's  success:  information  and  capabilities  must 
be  easily  and  intuitively  specified  and  accessed,  with  a  minimum  of 
training. 

Accordingly,  the  user  interface  depends  heavily  on  graphics. 
Navigation  through  models  and  libraries  is  facilitated  by  tree-based 
representations  (cf  Figure  1).  Menus  guide  users  through  activity 
selection,  information  specification  and  editing.  Figure  6  displays 
the  ASDL  multiple-choice  menu  interface  for  information  entry. 
(Figures  2  and  3  use  KEE's  frame  editor  to  show  all  of  the 
information  actually  contained  in  ASDL  data  structure  at  once.) 

Menu-driven  graphics  editors  are  employed  to  specify  relations: 
users  are  assisted  in  selecting  and  positioning  of  (labelled  box) 
icons  depicting  model  function  and  component  classes,  opening 
decomposition  windows,  and  drawing  and  labeling  (line)  icons 
representing  connectivity  and  function  flew  relations. 

Items  that  cannot  be  specified  graphically  (e.g.,  constraints, 
branching  and  looping  conditions  in  functional  flows,  and  functional 
behaviors),  are  described  declaratively .  Users  describe  such  data 
via  intelligent  menu-drivers  coupled  to  dedicated  languages. 

Language  interpreters  perform  appropriate  parsing,  generation  and 
installation  of  symbolic  expressions  or  code  (e.g.,  procedural 
attachments),  and  other  bookkeeping  measures. 

The  constraint  language  menu-drivers,  display  ingredients  which 
users  select  to  formulate  antecedent  and  consequent  clauses  for 
conditional  rules.  Rule  clauses  describe  predicate  expressions 
involving  model  object  classes  or  instances,  their  attributes  and 
values,  or  simple  (mathematical)  functions  of  such  values.  Clauses 
can  be  combined  using  the  standard  logical  connectives,  as  in  the 
costing  constraint  example  presented  earlier.  The  interpreter 
parses  the  result,  creates  a  constraint  relation  instance,  installs 
the  clauses  on  appropriate  slots,  and  sets  up  demons  that 
automatically  check  for  constraint  violations. 

Similarly,  menus  based  on  ASDL's  behavioral  language  enable 
users  to  specify  data  object  creation  and  destruction  and  changes  in 
component  or  data  object  attribute  values.  Menu  selections  for 
simple  control  structures  (e.g.,  conditionals,  loops,  sorts),  are 
also  available  to  describe  more  complex  function  behaviors. 

Language  enhancements  will  be  based  on  user  feedback  and  current 
experiments , 
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The  scenario  generator  portion  of  the  simulator  interface  is 
also  a  menu-driven  editor.  Scenario  events  are  basically  instances 
of  class  data  objects  or  actions  already  defined  in  the  model  system 
description.  Once  the  user  identifies  these  classes,  the  generator 
presents  multiple-choice  menus  (based  on  legal  values  facets)  that 
guide  users  in  specifying  event  attribute  values.  The  generator 
also  prompts  the  user  for  event  injection  time  and  functional  flow 
entry  point  and  adds  bookkeeping  slots  that  are  user-transparent. 


The  primary  simulator  control  loop  includes  an  interrupt 
monitor  that  allows  users  to  suspend  simulations  at  any  clock  pulse 
and  to  access  ASDL's  model  browsing  utilities  to  investigate  the 
current  state  of  the  system  model  and  active  data  objects.  The 
simulator  shell  also  automatically  maintains  a  graphic  execution 
trace  and  logs  of  scenario  runs  to  facilitate  behavioral  analysis. 


FUTURE  WORK 


The  utility  of  library-based  modeling  tools  depends  directly  on 
the  richness  of  their  libraries:  little,  if  any,  gain  in 
productivity  is  achieved  if  users  must  continually  create  new 
templates  as  they  construct  system  descriptions.  Accordingly,  ASDL 
will  be  exercised  using  various  acquisition  programs  in  order  to 
seed  the  generic  library  with  a  reasonable  spectrum  of  C3I  function 
and  component  templates.  As  ASDL  is  usea  in  specification 
development,  the  historical  library  will  grew  as  welL. 


Currently,  the  generic  modeling  library  depicts  functions  and 
components  used  in  military  communications  systems,  security 
requirements  (from  the  DoD  Trusted  Computer  System  Evaluation 
Criteria,  CSC-STD-003-85 ) ,  an  Air  Defense  Command  and  Control 
display  system,  and  several  radar  systems. 


The  existing  scenario  editor  only  supports  the  creation  of 
individual  test  events.  It  is  clearly  desirable,  and  relatively 
easy,  to  incorporate  a  batch  event  generator  similar  to  standard 
discrete  event  simulators.  Users  will  be  able  to  create  scenarios 
simply  by  specifying  event  types,  population  sizes,  and 
distributions  over  attribute  values  (e.g.,  injection  intervals, 
message  field  values). 


ASDL’s  current  analysis  capabilities  are  admittedly  somewhat 
limited,  particularly  with  respect  to  automated  analysis  of 
simulations.  The  reason  for  this  is  that  initial  project  efforts 
have  focused  on  defining  a  basic  representational  framework  and 
maintenance  utilities.  We  are  planning  to  investigate  automated 
behavioral  analysis  capabilities  and  model  post-processors  in  the 
near  future. 
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Consider,  for  example,  the  problem  of  comparing  simulation  runs 
produced  by  behavioral  models  of  a  system  across  acquisition  stages, 
driven  by  the  same  test  scenario(s).  One  such  comparison  amounts  to 
verifying  that  contractor  specifications  (e.g.,  SRS),  satisfy 
behavioral  aspects  of  customer  requirements  (e.g.,  SSS).  Another 
verifies  that  a  contractor  specification  (e.g.,  STLDD),  refines 
rather  than  alters  the  behavioral  aspects  of  preceding  contractor 
products  (e.g.,  SRS). 


Intuitively,  models  from  later  phases  of  the  development  cycle 
are  behaviorally  complete  and  consistent  just  in  case  they  produce 
the  same  kinds  of  events  in  the  same  sequences  that  were  generated 
by  simulations  of  earlier  system  models.  Devising  an  algorithm  to 
automate  such  a  mapping  across  simulation  event  logs  is  a  difficult 
problem. 


First,  earlier  models  (e.g.,  SSS),  have  a  coarser  event 
granularity  than  subsequent  models  (e.g.  SRS):  the  former  model 
describes  function  behaviors  at  a  system  level;  the  latter  depicts 
behavior  with  respect  to  a  particular  system  architecture,  function 
allocation,  and  specification  of  data  depicts  and  commands.  Second, 
the  combinatorics  of  event  mappings  are  severe  for  detailed 
behavioral  simulations  (e.g.,  hundreds  of  events). 


The  functional  approach  to  simulation  taken  by  ASDL  mitigates 
this  problem  somewhat  since,  by  construction,  the  execution  of  a 
function  on  particular  data  objects  is  modeled  in  terms  of  a  fixed, 
preprogrammed  collection  of  events.  Unfortunately,  the  remaining 
mapping,  between  functions  in  system  models  for  different 
acquisition  stages,  can  be  a  many-to-many  relationship.  ASDL 
currently  lacks  a  semantics  of  functionality  sufficiently  robust  to 
trace  behaviors  for  such  complex  cases. 


Future  work  will  address  this  problem.  It  should  also  be  noted 
that  automated  behavioral  analyses  such  as  the  capability  described 
here  are  simply  not  feasible  without  an  environment  like  ASDL  -  most 
tools  do  not  support  simulation  of  system  behavioral  descriptions 
across  a  suitable  range  of  acquisition  phases. 


The  most  challenging  assignment  is  to  make  ASDL  more 
intelligent.  Currently,  ASDL  operates  largely  as  a  passive  support 
tool:  users  perform  all  significant  decisions,  selecting 
appropriate  templates,  editing  and  connecting  them,  and  describing 
behaviors.  ASDL's  current  limitations  stem  from  the  fact  that  it 
only  stores  "whats"  information  -  knowledge  pertaining  to  systems 
and  system  ingredients,  per  se. 


More  active  assistance  capabilities  require  additional 
knowledge,  the  "hows”  and  "whys"  of  system  engineering  and  of 
acquisition  cycles:  why  components  can  or  cannot  be  connected 


together;  how  components  implement  functions;  why  some 
specifications  are  superior  or  inferior  to  others;  and  how  one  or 
more  requirements  entail  additional  "derived"  requirements. 

Our  initial  approach  for  resolving  this  problem  will  be  to 
enhance  the  generic  modeling  library  by  establishing  relational 
links  between  frame  templates  depicting  generic  functional  areas, 
functions,  and  components.  For  example,  the  functional  area  Sensor 
Functions  can  be  associated  with  specific  missions,  such  as  target 
detection,  tracking,  and  classification.  The  functions  resulting 
from  a  decomposition  of  this  functional  area  (e.g.,  signal 
generation,  transmission,  reception,  processing),  can  in  turn  be 
linked  with  behaviors  or  processes  involving  types  of  components 
(e.g.,  antennae,  processors,  displays).  Individual  functions 
(e.g.,  beam  sweep),  can  be  linked  to  specific  classes  of  system 
components  (e.g.,  scanners  such  as  rotodomes,  phased  array 
antennae),  and  with  sharply-defined  design  purposes  (e.g.,  to  obtain 
angular  scan  coverage). 

In  addition,  an  analogical  reasoning  capability  needs  to  be 
developed.  Enhanced  in  this  way,  ASDL  should  be  able  to  extract  and 
combine  library  elements  to  suggest  partial  functional 
decompositions  to  users  based  on  high-level  descriptions  of 
requirements  (e.g.,  fault-tolerant  message  processing).-  We  expect 
the  addition  of  "how"  and  "whys"  system  engineering  expertise  to 
ASDL  knowledge  bases  will  also  facilitate  the  solution  of  the 
behavioral  analysis  problem  described  above. 

Another  important  avenue  of  inquiry  is  the  integration  of  tools 
like  ASDL  into  the  existing  DoD  process.  In  particular,  it  is 
desirable  to  develop  a  post-processor  capable  of  translation  ASDL 
system  models  into  rough  drafts  of  DoD  (2167)  standard  documentation 
products.  However,  given  current  natural  technology  limitations  and 
the  fact  that  DoD  specifications  are  legally  binding  documents, 
additional  manual  processing  will  clearly  be  necessary. 

The  second  important  integration  problem  to  be  addressed  is  to 
interface  ASDL,  which  is  essentially  an  acquisition  process 
front-end  tool  to  back-end  tools  (i.e.,  for  detailed  design  and 
software  implementation.)  Example  back-end  tools  include 
(intelligent)  programming  environments  (e.g.,  dedicated  to  Ada  and 
Ada  PDL  code  generation  and  listing),  and  automated  programming 
systems.  This  work  is  an  important  prerequisite  to  developing  a 
fully  integrated  intelligent  environment  to  support  users  through 
the  complete  acquisition  process. 


SUMMARY 


ASDL  is  a  prototype  Al-based  tool  for  acquisition  support.  The 
objective  of  ASDL  is  to  assist  analysts  and  system  engineers  in 
generating  and  analyzing  symbolic  models  of  functional  requirements 
and  contractor  system  development  products  through  high  level 
design.  "Knowledge"  is  distributed  across  a  variety  of  structures 
in  ASDL:  the  knowledge  representation  substructure  (frames,  and 
procedural  attachments);  CrI  expertise  encoded  in  modeling  library 
templates;  specification  and  design  information  in  system  model 
knowledge  bases;  the  simulator  shell;  and  user  interface  and 
analysis  utilities. 
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Abstract:  We  are  prototyping  a  system  called  GRAPPLE  that  provides  intelligent  assistance 
to  the  programmer  carrying  out  the  process  of  programming.  The  architecture,  based  on  an 
AI  planning  paradigm,  can  provide  both  passive  and  active  assistance.  Passive  assistance, 
accomplished  by  plan  recognition ,Js  used  to  detect  and  avert  process  errors.  Active 
assistance,  accomplished  by  planning,  isused  to  automate  the  programming  process.  We 
will  be  demonstrating  the  plan  recognition  facilities,  and  the  programmer  assistance  based 
upon  plan  recognition,  in  our  current  prototype  running  on  a  Texas  Instruments  Explorer. 


In  GRAPPLE,  software  processes  are  defined  in  a  hierarchical,  state-based  plan  formalism 
that  has  been  engineered  to  meet  the  demands  of  complex  domains.  The  plan  recognizer 
has  the  ability  to  recognize  partial  plans  in  this  formalism,  focusing  on  a  best  interpretation 
when  there  is  not  yet  enough  information  to  disambiguate  competing  interpretations.  It  can 
also  handle  interleaved  actions  from  multiple,  top-level  plans.  The  types  of  errors  that  can 
be  detected  include  attempts  to  perform  an  action  whose  precondition  is  not  met,  or  one  that 
has  no  interpretation,  or  one  that  would  disrupt  a  previously  satisfied  precondition  for 
another  expected  action.  We  will  show  the  recognition  of  some  simple  software  process 
plans,  with  emphasis  on  the  algorithms  and  data  structures  internal  to  the  plan  recognizer. 
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Demonstration  of  the  Knowledge-Based 
Specification  Assistant1 
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Abstract 

This  demonstration  will  provide  an  overview  of  the  Knowledge-Based  Specification 
Assistant  system,  one  of  the  Knowledge-Based  Software  Assistant  projects  being  funded 
by  RADC.  This  system  assists  specifiers  in  developing  specifications,  evaluates 
specifications,  and  explains  the  contents  and  development  of  specifications.  Aspects  of 
each  of  these  three  kinds  of  capabilities  will  be  shown. 


1  This  research  is  supported  by  the  Air  Force  Command,  Rome  Air  Development  Center  under  Contract 
No.  F30602-85-C-0221.  Views  and  conclusions  contained  in  this  report  are  the  author’s  and  should  not  be 
interpreted  as  representing  the  official  opinion  or  policy  of  RADC,  the  U.S.  Government,  or  any  person  or 
agency  connected  with  them. 
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that  they  control.  The  specification  also  contains  a  some  invariants,  i.e.,  facts  which 
must  hold  true  of  the  specified  system  at  all  times.  In  the  menu  area  we  see  the 
structure-editing  commands  of  the  POPART  language  manipulation  system  [2]. 
POPART  is  one  of  the  general-purpose  tools  built  at  iSI  that  have  been  used  in 
constructing  the  Specification  Assistant.  The  structure-editing  commands  include 
commands  such  as  "Inward"  and  "Next  expression"  which  move  the  editor  focus  to 
different  parts  of  the  expression,  and  commands  like  "Insert  after"  and  "Replace" 
which  change  modify  the  specification  at  the  current  point  of  focus. 

2.  Specification  Assistance  Facilities 

The  Knowledge-Based  Specification  Assistant  assists  the  software  process  in  three 
ways: 

•  it  helps  the  specifier  construct  the  specification; 

•  it  evaluates  the  specification,  showing  what  behavior  it  describes; 

•  it  explains  the  specification  and  its  development,  so  that  specifiers  and  non¬ 
specifiers  alike  can  understand  what  the  specification  says. 

Each  of  these  facilities  will  be  shown  in  the  demonstration. 

The  Specification  Assistant  provides  semantics-oriented  specification  transformations, 
which  we  call  high-level  editing  commands,  for  refining  and  elaborating  specifications. 
A  history  of  the  specification  development  is  kept,  so  that  a  user  can  compare  earlier, 
abstract  versions  of  the  specification  with  later,  detailed  versions.  High-level  editing 
commands  allow  specifiers  to  first  state  what  system  functionality  would  ideally  be 
desirable,  and  then  refine  that  into  something  that  is  actually  achievable.  For  example, 
one  of  the  ideal  desirables  stated  in  the  specification  in  Figure  1-1  is 

INVARIANT  FOR  ALL  c I  controller ,  ac I  aircraft  II 
(should-control (c ,  ac))  =>  (controls (c,  ac)), 

meaning  that  every  aircraft  that  a  controller  should  control  is  in  fact  controlled.  In 

Figure  2-1,  we  see  the  specification  after  a  refinement  has  taken  place.  The  editing 

command  that  was  applied  was  "Maintain  Invariant  Reactively".  The  invariant  is  now 

gone;  instead,  there  is  a  demon  which  reacts  to  the  presence  of  uncontrolled  flights  and 


(On 


) 


attempts  to  make  then  controlled.  Although  the  invariant  is  gene,  ;t  b  still  present  in 
the  history.  .As  a  consequence,  a  specifier  can  always  look  back  to  find  out  vtiat  high- 
level  goals  some  complex  specification  is  attempting  to  maintain. 


KBSA  provides  two  evaluation  tools:  a  symbolic  evaluator,  and  a  simulator.  The 
symbolic  evaluator  is  designed  to  allow  the  user  to  execute  the  specification  on  abstract 
symbolic  data.  It  attempts  to  prove  general  theorems  about  how  the  specification 
operates  on  arbitrary  data.  For  example,  the  user  can  tell  the  symbolic  evaluator  to 
assume  that  there  is  some  arbitrary  number  of  aircraft  and  controllers  in  the  system, 
and  have  it  try  to  prove  that  all  aircraft  in  the  air  space  are  controlled.  If  the  symbolic 
evaluator  cannot  prove  it,  there  may  be  an  error  in  the  specification. 


The  simulator  allows  the  user  to  run  concrete  cases  through  the  specification,  and 
observe  the  result.  It  can  handle  more  complex  test  cases  than  the  symbolic  evaluator 
can,  but  it  cannot  prove  anything  about  how  the  specification  will  behave  in  general. 
One  important  feature  is  its  ability  to  simulate  the  behavior  of  a  number  of  processes 
executing  simultaneously. 


Our  basic  means  for  explaining  a  specification  is  to  generate  an  English  paraphrase  for 
different  parts  of  the  specification.  We  are  row  building  a  general-purpose  explanation 
shell  which  can  field  user  queries  and  plan  explanations  either  in  English  or  in  some 
other  presentation  medium.  The  English  paraphraser  will  be  placed  under  control  of 
this  explanation  engine.  As  a  result,  the  paraphrases  will  be  responsive  to  the  user’s 
interests;  formerly  the  paraphraser  would  paraphrase  the  entire  specification.  We 
ultimately  envision  extending  the  explanation  facility  so  that  maintainers  and  clients 
can  ask  questions  about  the  system  and  its  development,  and  so  that  specifiers  can  even 
ask  questions  about  how  to  use  the  Specification  Assistant’s  facilities. 
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